Firewall method and apparatus for industrial systems

ABSTRACT

Method and apparatus for use with systems including networked resources where communication between resources is via dual packet protocols wherein a first protocol includes a frame that specifies a destination device/resource and a data field and the second protocol specifies a final destination device/resource and includes a data field, where the second packets are encapsulated in the first protocol packet frames, the method including specifying access control information for resources, for each first protocol packet transmitted on the network, intercepting the first protocol packet prior to the first protocol destination resource, examining a subset of the additional embedded packet information to identify one of the intermediate path resources and the final destination resource, identifying the access control information associated with the identified at least one of the intermediate path resources and the final destination resource and restricting transmission of the first protocol packet as a function of the identified access control information.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.13/182,808, which was filed on Jul. 14, 2011 and entitled “FIREWALLMETHOD AND APPARATUS FOR INDUSTRIAL SYSTEMS,” which is a continuation ofU.S. Pat. No. 7,990,967, which was issued on Aug. 2, 2011 and entitled“FIREWALL METHOD AND APPARATUS FOR INDUSTRIAL SYSTEMS,” which claimspriority to U.S. Provisional Patent Application No. 60/641,839, whichwas filed on Jan. 6, 2005 and entitled “FIREWALL METHOD AND APPARATUSFOR INDUSTRIAL SYSTEMS,” and U.S. Pat. No. 7,990,967 also claimspriority to U.S. Provisional Patent Application No. 60/700,380, whichwas filed on Jul. 19, 2005 and also entitled “FIREWALL METHOD ANDAPPARATUS FOR INDUSTRIAL SYSTEMS,” all of which are incorporated hereinby reference.

STATEMENT REGARDING FEDERALLY SPONSORED RESEARCH OR DEVELOPMENT

Not applicable.

BACKGROUND OF THE INVENTION

The present invention generally relates to industrial control systems,and more particularly to systems and methods that provide secure andfirewall restricted Web-based access to control devices and componentsresiding on a non-IP network within an industrial environment.

A typical computer network comprises a plurality of interconnectedmicroprocessor-based devices with specialized (e.g., network) softwareand/or hardware that facilitates interaction between at least twodevices on the network. Such interaction can provide for a fast,efficient and cost-effective means to monitor, control and/or exchangeinformation amongst networked devices such as printers, plotters,workstations, copiers, etc.

Communication networks that link computing devices (e.g., servers,workstations, etc.) and other devices (e.g., lights, sprinkler systems,printer, plotters, etc.) together are typically categorized anddifferentiated through characteristics such as size and user base,architecture, and topology. For example, a network can be referred to asa Local Area Network (LAN) or a Wide Area Network (WAN), dependent onthe network size. A LAN is typically associated with a relatively smallgeographic area such as a department, a building or a group ofbuildings, and employed to connect local workstations, personalcomputers, printers, copiers, scanners, etc. while a WAN typically isassociated with networks that span larger geographical areas, and caninclude one or more smaller networks, such as one or more LANs. Forexample, a WAN can be employed to couple computers and/or LANs thatreside on opposite ends of a country and/or on opposite sides of theworld. The most popular WAN today is the Internet.

Various types of communication protocols have been developed tofacilitate communication between remotely located network devices. Forinstance, one common type of network based protocol is referred to as aninternet protocol (IP). In an IP network, a source device generates datapackets that include information (e.g., data to be delivered to adestination device, requests for certain data from a destination device,etc.) to be transmitted to a destination device, a source identifierthat identifies the source of the data packet and a destination addressassociated with the destination device. Here, the source identifier anddestination address fields in an IP packet are located in “framing”sections of the packet either before or after a data field. Hereinafter,unless indicated otherwise, the framing fields of an IP packet will bereferred to as IP packet frames. Once an IP data packet is transmitted,network routers and hubs that receive the packet analyze the packetframes to identify the destination address, attempt to identify the mostefficient way to deliver the packet to the destination device and thenretransmit the packet to another network device until the packet arrivesat the destination device. Here, the destination device is programmed toreceive the packet, decode the packet information and typically performsome process associated with the decoded information. For instance, afirst packet may be routed to a printer to print a document, a secondpacket may be routed to a light switch to turn on a light, a thirdpacket may be routed to a stock brokerage server to request informationabout a client's account, etc. Examples of IP based networks includeEtherNet/IP, EtherNet 10Base-T, 100Base-T (Fast EtherNet) and 1000Base-T(Gibabit EtherNet).

While IP networks have proven extremely useful in many applications, IPnetworks have several shortcomings that render the networks impracticalfor time sensitive applications. For instance, because IP networkrouting paths vary, the time required to transmit IP messages todestination devices varies appreciably. Similarly, excessive trafficover an IP network slows IP transmission rates so that packet deliverytime is dependent on unpredictable factors. In addition, in at leastsome cases, servers that communicate via IP, enforce timeout ruleswherein, if a packet has been transmitted from a source but thetransmission period exceeds some threshold time period (e.g., due tonetwork traffic), the message is discarded and has to be subsequentlyresent.

Thus, while IP networks are advantageous in applications wheretransmission time is not critical (e.g., a printing application, arequest for information from a broker, sending an e-mail, etc.), IPnetworks have not been suitable in cases where information has to betransmitted almost instantaneously and at least within predictable timeperiods. Industrial controls is one application where unpredictablerouting delays have rendered IP networks impractical in the past.

An exemplary industrial manufacturing line may include several machiningstations (and associated devices and subassemblies—e.g., switches,sensors, motor starters, pushbuttons, I/O blocks, welders, robots,drives, bar code readers, etc.) along a transfer line, severalprogrammable logic controllers (PLCs), one or more human-machineinterfaces (HMIs) and a network that links the other components togetherwhere the PLCs are programmed to read inputs from stations and transferline devices and provide outputs to the devices as a function of controlprograms stored in the PLCs. In many cases device and subassemblycontrol at each station and between stations or between stations and thetransfer line may have to be precisely synchronized in order for theline devices and assemblies to function properly and safely (e.g., afirst robot arm could be damaged if the arm is driven into a linestation prior to a second robot arm being removed from the station).Where device and subassembly timing is important, unpredictable IPnetwork delays and periodic failures cannot be tolerated.

Early industrial control systems employed discrete signal wires betweensensors and controllers and between controllers and actuators to ensurefast and predictable response times where control was modified by directconnection to the controller.

More recently, small groups of signal sensors and actuators have beentied to remote I/O concentrators where the concentrators have beennetworked to the controllers. In some cases, devices have been designedwhere network interfaces are embedded in the devices themselves.Exemplary devices of this type include DeviceNet and ControlNet devicesthat have been developed by Rockwell Automation. DeviceNet, ControlNetand other types of devices that include embedded network interfaces willbe referred to generally hereinafter as non-IP devices.

In addition to developing non-IP devices suitable for use in industrialenvironments, industrial networking protocols have been developed foruse with the non-IP devices where the industrial protocols use datapacket formats that specify specific network paths from source devicesto destination devices and therefore can transmit data in predictabletime periods. One exemplary type of industrial protocol for use withDeviceNet and ControlNet devices is referred to as the control andinformation protocol or the common industrial protocol (CIP). Anotherexemplary non-IP protocol suitable for use with some types of industrialdevices is referred to as Data Highway Plus. Other non-IP protocols arecontemplated. Where an Ethernet links an HMI to a destination ControlNetor DeviceNet device through three additional ControlNet or DeviceNetdevices (hereinafter “transmission path devices”) arranged in a series,a CIP data packet will specify the packet source, information to bedelivered to a destination device, the destination device address and aspecific path through the networked devices from the source to thedestination device.

Here, the path specification includes the addresses of each of the threeintervening transmission path devices and the order in which the devicesare linked. For instance, in the present example that includes a threedevice path and a destination device, the path data includes first,second and third transmission path device addresses and identifies thedestination device address separately. During transmission of the CIPpacket, the source routes the packet to the address of the first devicein the path, the first device identifies the second path device addressin the packet and routes the packet to the second address. The secondpath device identifies the third path device address in the packet androutes the packet to the third device address and the third deviceidentifies the destination device address and routes the packet to thedestination device to complete delivery of the packet. The specifiedpath method used in CIP communication, unlike IP, results in adeterministic communication protocol that is suited for use inindustrial environments.

Even more recently, for various reasons, industry members have adaptedthe specialized industrial network devices such as ControlNet andDeviceNet devices for use with open standards like Ethernet. Forinstance, in the case of CIP, CIP packets have been encapsulated withinEthernet or IP packet frames for routing via Ethernet. The result ofthis adaptation is that programming interfaces and sometimes controllerto device interfaces are now communicating via Ethernet IP.

One advantage of non-IP devices like DeviceNet, ControlNet, etc., isthat the devices can be configured into a non-IP network that is lessexpensive than a typical IP network as the need for network switches iseliminated. In addition, DeviceNet, ControlNet and other similar networkconfigurations have intrinsic safety features that are not provided byan IP network. For this reason, in many cases, it is most advantageousto configure hybrid networks including some IP network devices and somenon-IP network devices specially designed for industrial applications(e.g., DeviceNet, ControlNet devices).

While industrial control has historically been limited to confined andsecure spaces such as within a manufacturing facility, in cases wherepure Ethernet or hybrid networks (e.g., including a combination of IPand non-IP (e.g., DeviceNet, ControlNet) network devices) are used toroute data between devices, the transparency of the Ethernet routingmechanism makes it possible to remotely monitor and control thenetworked industrial devices. The possibility for remote monitoring andcontrol advantageously allows more flexible system layouts to beconfigured and reduces overall system costs where Ethernetinfrastructure already exists to support other facility needs.

Unfortunately, one problem with pure Ethernet and hybrid networks isthat the transparency of the Ethernet routing mechanism componentspresents security problems. For instance, where a LAN operated by abrokerage firm and including a server is linked to the Internet to allowcustomers to access account information, an unscrupulous computer hackermay attempt to access the LAN via an Internet connection to obtaininformation about one of the firm's client's accounts. As anotherinstance, a hacker may maliciously attempt to access a banks softwarevia the Internet to load a virus thereon that could scramble the bank'srecords and negatively affect the bank's business. As one otherinstance, a hacker may attempt to access a PLC and alter an industrialcontrol program thereby causing damage to machine line componentscontrolled by the PLC.

In addition to unscrupulous persons doing unsavory things via networkedinterfaces, in many cases even well intentioned network users may beable to unintentionally cause problems if they access networked devices.For instance, in the case of a maintenance engineer at a manufacturingfacility, while the engineer may be trained to maintain a first type ofmanufacturing line, the engineer may not be trained to maintain a secondtype of manufacturing line. While in a facility including the firstline, the engineer may have to be proximate the first line to performdiagnostics procedures, check operating values, etc., wherein theproximity requirement and visual feedback ensures that the engineer isaccessing first line devices, not second line devices. Where remoteaccess is facilitated via a pure Ethernet or hybrid system, proximityand visual feedback cannot be relied upon and the end result could bethat the engineer unknowingly accesses second line devices rather thanfirst line devices.

To ensure that unintended network access does not occur, informationtechnology (IT) firewalls have been developed that, in effect, separateLANs and other sub-networks from the Internet and that operate asgatekeepers to keep unauthorized network users from accessing thesub-networks while still allowing access to authorized network users. Tothis end, a firewall generally intercepts attempts to access associatedsub-networks and requires some type of proof of identity from a networkuser attempting to access the sub-networks prior to allowing access.Here, proof of identity may require entry of a user name and password ormay be transparent to a network user (i.e., information transmitted fromthe user's interface device may indicate identity which is automaticallyidentified by the firewall). Where a network user is not authorized toaccess a sub-network, the firewall restricts access and may perform somesecondary security process such as creating a log, activating an alarm,etc.

While conventional IT firewalls work well in the context of pure IPcommunication, where a non-IP industrial protocol (e.g., CIP) isembedded within an IP or Ethernet frame, the embedded non-IP protocolcould be used to perform unauthorized activities despite a properlyfunctioning IT firewall. Here, when an IP or Ehternet packet includingan embedded non-IP packet is received by a firewall, an IT firewallalgorithm interrogates the IP packet frame information to determine ifthe packet should be passed through the firewall to a destination deviceidentified in the IP packet frame. If, however, the destination devicedesignated in the IP packet frame routes the packet further based on thenon-IP routing information (e.g., addresses in an embedded CIP packet),the ultimate destination designated by the non-IP routing information isnot protected. This “carry-through” routing is a concern whether the CIPpacket is routed via Ethernet or some other native industrial networksuch as DeviceNet or ControlNet.

Thus, it would be advantageous to have a method and apparatus thatallows devices linked to an IP network to access industrial and otherdevices linked to a non-IP network only when the accessing device orperson using the accessing device has authority to access thedestination device.

BRIEF SUMMARY OF THE INVENTION

The following presents a simplified summary of the invention in order toprovide a basic understanding of some aspects of the invention. Thissummary is not an extensive overview of the invention. It is intended toneither identify key or critical elements of the invention nor delineatethe scope of the invention. Its sole purpose is to present some conceptsof the invention in a simplified form as a prelude to the more detaileddescription that is presented later.

It has been recognized that network security problems can occur whenadditional routing information is encapsulated or embedded in the datafield of an IP data packet that specifies a destination device orresource that is different than the destination device or resourcespecified in the IP packet frame. Specifically, where it is desired torestrict access to certain devices within a control configurationembedded routing information has enabled packets to be passed throughconventional it firewalls enabling access to restricted devices.

According to at least some inventive aspects, firewalls are providedwithin a network wherein data packets received thereby are decapsulatedso that at least an ultimate destination device or resource isidentified. Access rules are applied to determine if the packet shouldbe transmitted further to facilitate access or if a security function(e.g., discarding the packet, sending a reject message, activating analarm, etc.) should be performed. In at least some cases all routinginformation is identified and analyzed and whenever any device in arouting path is not to be accessed for any reason, even if the ultimatedestination device is accessible, the a security function is performed.

Consistent with the above, at least some embodiments of the inventioninclude a method for use with a system including networked resourceswhere communication between resources is via at least first and secondprotocols wherein the first protocol includes a first protocol packetincluding a source identifier, a first protocol destination identifierthat indicates a first protocol destination resource and a firstprotocol data field, the second protocol including a second protocolpacket including at least one second protocol destination identifierthat indicates a second protocol destination resource and a secondprotocol data field, wherein at least some communication betweenresources includes first protocol packets including second protocolpackets embedded in the first protocol data fields, packet transmittingand receiving resources being source and destination resources,respectively, the method for controlling communication between resourcesand comprising the steps of: specifying access control information forat least a subset of the resources where the access control informationincludes at least one of characteristics of first protocol packets thatare authorized to be transmitted to an associated resource andcharacteristics of first protocol packets that are unauthorized to betransmitted to an associated resource, for each first protocol packettransmitted on the network that includes a second protocol packetembedded in the first protocol data field: (i) intercepting the firstprotocol packet prior to the first protocol destination resource; (ii)examining at least a subset of the embedded second protocol packetinformation to identify the second protocol destination resource; (iii)identifying the access control information associated with the secondprotocol destination resource, (iv) identifying at least a subset ofcharacteristics of the first protocol packet, (v) comparing the firstprotocol packet characteristics to the access control informationassociated with the second protocol destination resource and (vi)restricting transmission of the first protocol packet as a function ofthe comparison results.

In at least some cases the step of specifying access control informationincludes, for each of at least a subset of destination resources,specifying source resources authorized to communicate with thedestination resource. In some cases the step of identifying at least asubset of the characteristics of the first protocol packet includesidentifying the source of the first protocol packet and the step ofcomparing the first protocol packet characteristics to the accesscontrol information associated with the destination resource includescomparing the source of the first protocol packet to the resourcesauthorized to communicate with the destination resource. In someembodiments the step of restricting includes, when the first protocolpacket source is not authorized to access the second protocoldestination resource, halting transmission of the first protocol packet.In still other embodiments the step of restricting includes, when thefirst protocol packet source is not authorized to access the secondprotocol destination resource, at least one of activating an alarmsignal and providing a signal back to the source indicating that thepacket has been halted.

In some cases, the step of specifying access control informationincludes specifying packet characteristics (PCs) that includecharacteristics identifiable directly from the first protocol packet.

In some cases the step of specifying access control information includesspecifying non-packet characteristics (NPQs) that includecharacteristics other than those identifiable directly from the firstprotocol packet. Here, the NPQs may include at least a subset of a timeassociated with the first protocol packet transmission, the location ofthe source resource, where a person initiates the first protocol packettransmission, the identity of the initiating person and, where a personinitiates the first protocol packet transmission, characteristics of theinitiating person.

In some embodiments the step of specifying access control informationfurther includes specifying times during which resources can communicatewith other resources, the method further including the step of, when afirst protocol packet that includes an embedded second protocol packetis received, identifying a time associated with the received packet, thestep of comparing including comparing the packet associated time withthe specified times.

In some cases the first protocol is one of an Ethernet protocol and anIP protocol. In some cases the second protocol is one of a commonindustrial protocol (CIP) and a Data Highway Plus protocol. In somecases the steps of specifying at least first and second priorities fornetwork transmissions and, wherein, the step of restricting transmissionincludes transmitting as a function of the specified priorities and thepacket characteristics.

In some additional embodiments the step of specifying access controlinformation includes the step of specifying locations of sourceresources from which communications with associated resources areallowed, the method further including the step of identifying thelocation of a source resource that transmits a first protocol packetthat includes an embedded second protocol packet and the step ofcomparing further including comparing the identified source resourcelocation with the specified source resource location.

In some cases each destination resource includes at least one of aprogrammable logic controller (PLC), a human-machine interface (HMI), asensor, an actuator, a drive, and a remote input/output device. In somecases the step of specifying access control information includesspecifying characteristics of persons authorized to communicate withassociated resources, the step of identifying at least a subset of thecharacteristics of the first protocol packet including identifyingcharacteristics of a person that initiates a communication and the stepof comparing including comparing the specified and identifiedcharacteristics.

In some embodiments the embedded protocol packet specifies a path ofresources to a final destination resource, the method further includingidentifying access control information associated with each of the pathresources, comparing the first protocol packet characteristics to theaccess control information associated each of the path resourcesresource and restricting transmission of the first protocol packet as afunction of the results of the comparison to the access controlinformation associated with the path resources.

In addition, some inventive embodiments include a method for use with asystem including networked resources where communication betweenresources is via at least first and second protocols wherein the firstprotocol includes a first protocol packet including a source identifier,a first protocol destination identifier and a first protocol data field,the second protocol including a second protocol packet including atleast one second protocol destination identifier and a second protocoldata field, wherein at least some communication between resourcesincludes first protocol packets including second protocol packetsembedded in the first protocol data fields, packet senders and intendedrecipient's being source and destination resources, respectively, themethod for controlling communication between resources and comprisingthe steps of specifying access control information for at least a subsetof the resources where the access control information includes at leastone of characteristics of first protocol packets that are authorized tobe transmitted to an associated resource and characteristics of firstprotocol packets that are unauthorized to be transmitted to anassociated resource, for each first protocol packet transmitted on thenetwork that includes a second protocol packet embedded in the firstprotocol data field: (i) intercepting the first protocol packet prior tothe second protocol destination resource, (ii) examining at least asubset of the embedded second protocol packet information to identifythe second protocol destination resource, (iii) examining the firstprotocol packet information to identify at least one additional resourcein addition to the second protocol destination resource, (iv)identifying the access control information associated with the secondprotocol destination resource and the access control informationassociated with the additional resource, (v) identifying at least asubset of characteristics of the first protocol packet, (vi) comparingthe first protocol packet characteristics to the access controlinformation associated with the second protocol destination resource andcomparing the first protocol packet characteristics to the accesscontrol information associated with the additional resource and (vii)restricting transmission of the first protocol packet as a function ofthe comparison results. Here, the additional resource may be the firstprotocol packet destination resource. In the alternative, the secondprotocol packet may specify at least one path resource to the secondprotocol packet destination resource through which data is to be routedbetween the first and second protocol packet destination resources andthe step of identifying at least one additional resource may includeidentifying the at least one path resource.

In addition, some embodiments include a method for use with a systemincluding networked resources where communication between resources isvia at least first and second protocols wherein the first protocolincludes a first protocol packet including a source identifier, a firstprotocol destination identifier and a first protocol data field, thesecond protocol including a second protocol packet including at leastone second protocol destination identifier and a second protocol datafield, wherein at least some communication between resources includesfirst protocol packets including second protocol packets embedded in thefirst protocol data fields, packet senders and intended recipient'sbeing source and destination resources, respectively, the method forcontrolling communication between resources and comprising the steps ofspecifying access control information for at least a subset of theresources where the access control information includes at least one ofcharacteristics of first protocol packets that are authorized to betransmitted to an associated resource and characteristics of firstprotocol packets that are unauthorized to be transmitted to anassociated resource, for each first protocol packet transmitted on thenetwork that includes a second protocol packet embedded in the firstprotocol data field, intercepting the first protocol packet prior to thesecond protocol destination resource, examining at least a subset of theembedded second protocol packet information to identify the secondprotocol destination resource, examining the first protocol packetinformation to identify at least one additional resource in addition tothe second protocol destination resource, identifying the access controlinformation associated with the second protocol destination resource andthe access control information associated with the additional resource,identifying at least a subset of characteristics of the first protocolpacket, comparing the first protocol packet characteristics to theaccess control information associated with the second protocoldestination resource and comparing the first protocol packetcharacteristics to the access control information associated with theadditional resource and restricting transmission of the first protocolpacket as a function of the comparison results.

In at least some cases the additional resource is the first protocolpacket destination resource. In at least some cases the second protocolpacket specifies at least one path resource to the second protocolpacket destination resource through which data is to be routed betweenthe first and second protocol packet destination resources and whereinthe step of identifying at least one additional resource includesidentifying the at least one path resource.

Moreover, some embodiments include a method for controllingcommunications between a source device linked to an IP network and atarget device linked to a non-IP network wherein the target deviceincludes at least one object, each communication specify at least oneobject and at least one service related to the target device, the methodcomprising the steps of providing an access control database thatcorrelates the source device with target devices, objects and serviceswhere the correlated target devices include devices that the source canaccess and the correlated services include services that the source caninitiate at the correlated object, receiving at least one communicationtransmitted from the source to the target device, decapsulating thecommunications to identify the target device and related at least oneobject and the at least one service, comparing the identified targetdevice, at least one object and at least one service with the targetdevice, object and service information in the database and selectivelytransmitting the at least one communication to the target device as afunction of the comparison.

In at least some cases the correlated object includes a combination of aclass, an instance of a class, an attribute of a class and an attributeof an instance of a class.

Furthermore, some embodiments include a method for controllingcommunications between a source device and a target device, the methodcomprising the steps of providing an access control database thatcorrelates the source device with target devices where the correlatedtarget devices include devices that the source can access for at leastone purpose, providing a firewall between the source device and thetarget device, intercepting a connection open packet transmitted by thesource device to the target device that is intended to open a connectionpath between the source and the target devices, using the access controldatabase to determine if the source device may access the target deviceand transmitting the connection open packet toward the target devicewhen the source device may access the target device.

In addition, some embodiments include a method for minimizing processingdelays when unauthorized communications occur on a system that includesa source device, a target device and a communication stack, the sourcedevice sequentially generating and transmitting communication packetsfor each of the stack communications and, after a packet is transmitted,waiting for a response packet for at least a subset of thecommunications prior to transmitting another communication packetassociated with another of the stack communications, the methodcomprising the steps of providing a firewall linked to the system,transmitting an original communication packet from the source devicethat targets the target device, via the firewall intercepting theoriginal communication packet, encapsulating a spoof response packetthat simulates a response from the target device and that is of a formthat will be accepted by the source device as a legitimate response fromthe target device, transmitting the spoof response packet to the sourcedevice and, via the source, accepting the spoof response packet as alegitimate response packet from the target device and

moving on to process the next communication in the stack.

In some cases the method further includes the steps of providing anaccess control database useable to identify unauthorized communicationson the system and after intercepting the original communication packetand prior to encapsulating, using the access control database toidentify that the communication packet is associated with anunauthorized communication.

In some cases the step of encapsulating includes obtaining at least someinformation from the original communication packet and using theobtained information to instantiate at least a subset of the responsepacket. In some cases the original request packet includes atarget-originator (T-O) ID and wherein the obtained information includesthe T-O ID from the original request packet.

In some cases the obtained information includes information identifyingthe source device and information identifying the target device. In somecases the step of encapsulating further includes generating at leastsome bogus information to instantiate at least a subset of the responsepacket information and instantiating at least portions of the responsepacket with the bogus information. In some cases the step ofencapsulating further includes generating at least some bogusinformation to instantiate at least a subset of the response packetinformation and instantiating at least portions of the response packetwith the bogus information.

At least some embodiments include a method for use with a systemincluding networked resources where communication between resources isvia at least first and second different protocols wherein the firstprotocol includes a first protocol packet including a source identifier,a first protocol destination identifier that indicates a first protocoldestination resource and a first protocol data field, the secondprotocol including a second protocol packet including at least onesecond protocol destination identifier that indicates a second protocoldestination resource and a second protocol data field, wherein at leastsome communication between resources includes first protocol packetsincluding additional packets embedded in the first protocol data fields,one of the additional embedded packets specifying a final destinationresource and each of the other additional embedded packets specifying anintermediate path resource, at last one of the additional embeddedpackets being a second protocol packet, the method for controllingcommunication between resources and comprising the steps of specifyingaccess control information for at least a subset of the resources, foreach first protocol packet transmitted on the network that includesadditional embedded packets, (i) intercepting the first protocol packetprior to the first protocol destination resource, (ii) examining atleast a subset of the additional embedded packet information to identifyat least one of the intermediate path resources and the finaldestination resource, (iii) identifying the access control informationassociated with the identified at least one of the intermediate pathresources and the final destination resource and (iv) restrictingtransmission of the first protocol packet as a function of theidentified access control information.

Here, in some cases the step of restricting transmission includesidentifying at least a subset of characteristics of the first protocolpacket, comparing the first protocol packet characteristics to theidentified access control information and restricting transmission as afunction of the comparison. In some cases the step of examining includesexamining to identify each of the intermediate path resources and thefinal destination resource and wherein the step of identifying accesscontrol information further includes identifying access controlinformation for each of the intermediate path resources and the finaldestination resource.

In some cases each of the additional embedded protocol packets is of thesecond type. In some embodiments the step of identifying at least asubset of characteristics of the first protocol packet includesidentifying at least a subset of the characteristics of each of thefirst and the embedded protocol packets. In some cases the accesscontrol information includes at least one of characteristics of firstprotocol packets that are authorized to be transmitted to an associatedresource and characteristics of first protocol packets that areunauthorized to be transmitted to an associated resource.

In some embodiments the at least one protocol packet generated by afirst protocol packet source requires a response from at least one ofthe intermediate path resources and the final destination resourceincluding specific identifying information and wherein step ofrestricting includes, when a first protocol packet source is notauthorized to communicate with the second protocol destination resource,encapsulating the specific identifying information in a response packetand transmitting the response packet to the first protocol packetsource.

At least some embodiments also include apparatus for performing theprocesses described above and hereafter.

The following description and annexed drawings set forth in detailcertain illustrative aspects of the present invention. These aspects areindicative, however, of but a few of the various ways in which theprinciples of the invention may be employed and the present invention isintended to include all such aspects and their equivalents. Otheradvantages and novel features of the present invention will becomeapparent from the following detailed description of the invention whenconsidered in conjunction with the drawings.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

The invention will hereafter be described with reference to theaccompanying drawings, wherein like reference numerals denote likeelements, and:

FIG. 1 is a schematic view of a system including firewalls according toat least some aspects of the present invention;

FIG. 2 is a schematic view of an exemplary dual protocol data packetincluding a non-IP data packet embedded or encapsulated within an IPtype data packet;

FIG. 3 is a schematic view of an exemplary simple access controldatabase that may be used by the firewalls of FIG. 1;

FIG. 4 is a flow chart illustrating an exemplary access controlrestricting method wherein access to control devices is limited as afunction of which source is used to attempt the control;

FIG. 5 is a flow chart illustrating one exemplary secondary functionthat may be substituted for a portion of the method of FIG. 4;

FIG. 6 is similar to FIG. 5, albeit illustrating a different secondarysecurity function;

FIG. 7 is similar to FIG. 5, albeit illustrating a third securityfunction;

FIG. 8 is a schematic illustrating an exemplary HMI/user database thatmay be employed by the firewalls of FIG. 1;

FIG. 9 is a flow chart similar to the flow chart of FIG. 4, albeitillustrating a method wherein device access is restricted as a functionof user identity;

FIG. 10 is an access control database similar to the database of FIG. 3,albeit illustrating a more complex embodiment wherein, in addition touser identity, other non-packet characteristics are included, priorityinformation is included and specific application restrictions areincluded;

FIG. 11 is yet another exemplary access control database includingrestrictions as a function of user type and a specification thatidentifies types corresponding to specific users;

FIG. 12 is a flow chart illustrating a sub-method that may besubstituted for a portion of the method of FIG. 9 to facilitateprioritization of data packets when they are passed by the firewalls ofFIG. 1;

FIG. 13 is a flow chart of a sub-process that may be substituted for aportion of the process of FIG. 9 wherein the firewalls of FIG. 1 analyzemultiple data packets when necessary to identify intended applicationand restrict as a function of applications to be performed;

FIG. 14 is a flow chart illustrating yet another method according to atleast some aspects of the present invention wherein a security server ofFIG. 1 learns access requirements and populates a portion of an accesscontrol database corresponding to a specific HMI user type;

FIG. 15 is a screen shot or window that may be provided via anadministrator's interface of FIG. 1 for manually specifying accesscontrol for a particular system user;

FIG. 16 similar to FIG. 15, albeit illustrating a different accesscontrol configuring window;

FIG. 17 a flow chart illustrating a method whereby a systemsadministrator manually specifies access control information;

FIG. 18 is a schematic view of an exemplary dual protocol data packetincluding a CIP data packet embedded or encapsulated within an IP typedata packet where the data packet corresponds an unconnected send typeservice;

FIG. 19 is a schematic view of an exemplary object path/service field asillustrated in FIG. 18 including a plurality of subfields;

FIG. 20 is a flow chart illustrating a subprocess that may besubstituted for a portion of the method of FIG. 4 for processing anunconnected send packet;

FIG. 21 is similar to FIG. 18, albeit illustrating a packet forinitiating an unconnected forward open request service;

FIG. 22 is a schematic diagram illustrating a forward open table thatmay be generated and maintained by one of the firewalls in FIG. 1 forkeeping track of open connection paths between sources and targetnetwork devices;

FIG. 23 is similar to FIG. 18, albeit illustrating a packet associatedwith an unconnected forward open reply service;

FIG. 24 is similar to FIG. 18, albeit illustrating a packetcorresponding to a connected send service;

FIG. 25 is similar to FIG. 18, albeit illustrating a packet associatedwith an unconnected forward close service;

FIG. 26 is a portion of a flow chart illustrating a method that may beperformed by one of the firewalls in FIG. 1 to form and eliminate openconnection paths;

FIG. 27 is another portion of the flow chart illustrated in FIG. 26;

FIG. 28 is an exemplary access control database that is similar to thedatabase of FIG. 3, albeit including additional information;

FIG. 29 is a schematic illustrating an exemplary server including acommunication stack that is linked to a decapsulating firewall;

FIG. 30 is similar to FIG. 18, albeit illustrating a spoofed responsepacket;

FIG. 31 is a flow chart illustrating a method associated with acommunication stack; and

FIG. 32 is a sub-process that may be substituted for a portion of themethod of FIG. 20 for generating a spoofed response packet.

DETAILED DESCRIPTION OF THE INVENTION

The present invention is now described with reference to the drawings,wherein like reference numerals are used to refer to like elementsthroughout. In the following description, for purposes of explanation,numerous specific details are set forth in order to provide a thoroughunderstanding of the present invention. It may be evident, however, thatthe present invention may be practiced without these specific details.In other instances, well-known structures and devices are shown in blockdiagram form in order to facilitate describing the present invention.

As used herein, the term “device,” or “resource” is intended to refer toa computer-related entity, either hardware, a combination of hardwareand software, software, or software in execution. For example, a devicecan be, but is not limited to, a process running on a processor, aprocessor, an object, an executable, a thread of execution, a program, amicroprocessor, a processing unit and/or a computer, and hardware (e.g.,a sensor or actuator) performing a process, etc.

Referring now to FIG. 1, the present invention will be described in thecontext of an exemplary system 10 including a security subsystem 25,source devices collectively identified by numeral 27, a series ofdecapsulating firewalls, three of which are identified by numerals 28,30 and 31, and an industrial control configuration 21 including aplurality of industrial control devices such as programmable logiccontroller PLC1 and automated devices including devices D1, D2, D3, etc.The industrial control devices (e.g., PLC1, devices D1, D2, etc.) arearranged in a manufacturing facility or the like to perform someindustrial process. For example, the devices may be arranged toautomatically assemble automobile seat components including cushions,springs, motors, rollers, support mechanisms, headrest extensions,covering material, etc. In this regard, in addition to PLCs to controlother devices, devices may includes sensors, actuators, data collectingprocessors and devices, input/output concentrators, etc.

To facilitate control, monitoring exchange of data and configuring ofthe devices, the configuration 21 devices are linked via a network asillustrated. For example, referring again to FIG. 1, automated device D6is linked to automated device D1, device D1 is linked to device D0 anddevice D0 is linked to PLC1. Similarly, device D6 is linked to device D5and device D5 is linked to device D4. As illustrated, more than onedevice can be linked to another device. For instance, each of devicesD2, D3 and D6 are linked to different output ports of device D1.Although only a small number of industrial control devices areillustrated in FIG. 1, it should be appreciated that, in manyapplications, several thousand devices may be linked together to form anintricate web of control components for facilitating complex industrialprocesses.

Each of the devices D0, D1, D2, etc. is assigned a specific networkaddress and includes a processor capable of identifying networkcommunications transmitted to the associated address. In addition, thedevice processors are programmed to examine received information packetsto identify if the device is the final destination device or simply onedevice in a transmission path to some other destination device. Wherethe device is the final destination device, the processor uses packetdata to perform some associated process. Where the device is not thefinal destination device, the processor transmits at least a portion ofthe received packet information to the next device in the transmissionpath.

As known in the automation industry, industrial control components maybe of various network types, including, but not limited to, EtherNet,DeviceNet, ControlNet, etc. For instance, in FIG. 1, device D4communicates with device D5 via ControlNet while device D5 communicateswith device D6 via DeviceNet and device D1 communicates with device D2via EtherNet. Also, as illustrated, one device may be capable ofcommunicating in several different protocols, depending on the nextdevice to which a packet is to be routed. For instance, device D1communicates via a DeviceNet protocol with each of devices D2 and D6 butcommunicates via a ControlNet protocol with device D3.

In general, non-IP protocols are different than IPs in the way in whichpackets of information that facilitate the protocol are formed and theway in which networked devices use the packet information to route to afinal destination device. In this regard, while IPs typically specify apacket source and a destination device and rely on routers and switchesto deliver information packets from a source to a destination device,non-IPs specify a specific network path through a chain of devices fordelivering information packets from a source to a destination device.For example, referring once again to FIG. 1, to deliver a packet fromfirewall 30 to automated device DN, a non-IP packet may specify a path37 including device D4, device D5, device D6, and so on all the waythrough to device DN. Here, when device D4 receives the CIP packet,device D4 recognizes that the packet should be transmitted to device D5and performs that transmission. Similarly, when device D5 receives thepacket, device D5 determines that the packet should be transferred todevice D6 and performs that transmission. This process continues untilthe packet is received by device DN. A second exemplary path 35 throughPCL1, and devices D0, D1, D6, etc. to device DN is illustrated. In FIG.1, communications that originate outside configuration 21 are IPcommunications and the network over which those communications travel isreferred to as an IP network 26 and communications that originate withinconfirmation 21 are referred to as non-IP communications (e.g., CIPcommunications, Data Highway Plus, etc.) and the network (not labeled)is referred to as a non-IP network.

Referring still to FIG. 1, sources 27 include any type of component thatmay be used to attempt to access any of the industrial controlcomponents or devices included in control configuration 21. Here, theterm “access” is used in a general sense to refer to the ability tomonitor, control, configure and/or obtains information from adestination device. In addition, each source 27, etc. may also be usedto access other devices linked to IP network 26 via pure IPcommunications. Exemplary sources S2, SN may include data monitoring andarchiving servers, maintenance servers that analyze data obtained fromsystem components and devices other IP or non-IP networks includingother devices, servers that perform control and safety operations withrespect to system components and devices, etc.

In addition, at least some of the sources may include human-machineinterfaces (HMIs) to enable information technology personnel,maintenance personnel, an administrative person, etc., to access systemdevices and components. For example, illustrated sources S1 and S3 arelaptop computers that run browser software to interact with laptop usersto facilitate access to configuration 21 devices. Other exemplary HMIsmay include an electronic notepad, a personal computer, a palm pilot, ahand-held computer, a personal digital assistant, a mainframe computer,a cell phone, a “dumb” terminal, a tablet PC, etc. Hereinafter, laptopS1 will be referred to as HMI S1 and a person using HMI S1 will bereferred to as a “user” unless indicated otherwise. Similarly, laptop S3will be referred to as HMI S3. In addition, while sources S2, SN, etc.may access or attempt to access configuration 21 devices eitherautomatically (e.g., to periodically collect and archive operating data)or when a user performs some activating process, to simplify thisexplanation, access restriction will be described in the context of HMIS1 unless indicated otherwise. Moreover, while HMI S1 could be used toattempt to access any of configuration 21 devices, unless indicatedotherwise, the present inventions will be described in the context ofactivity that causes HMI S1 to attempt to access device DN via path 37(e.g., through devices D4, D5, D6, etc.).

Referring still to FIG. 1, HMI S1 accesses control devices inconfiguration 21 by forming and transmitting IP data packets via IPbased network 26 that include information necessary to deliver thepackets to the destination devices. To this end, because system 10components between HMI S1 and a destination device within configuration21 communicate using both IP and non-IP, the data packet generated byHMI S1 to access an industrial control device must include informationthat facilitates both routing on IP network 26 to a device at the “edge”of the IP network and subsequent routing via the non-IP network betweenconfiguration 21 devices.

Referring now to FIG. 2, an exemplary data packet 32 that may begenerated by HMI S1 in FIG. 1 to access one of the industrial controldevices in configuration 21 is illustrated. Exemplary packet 32 is atypical IP packet and, to that end, includes a frame that specifiespacket source and destination device and a data field within the frame.In FIG. 2, the IP packet frame includes a source IP field 34 and an IPdestination address field 36 as well as an end packet field 48. The IPpacket data field is identified by numeral 49 in FIG. 2 and includesfields 38, 40, 42, 44 and 46 as illustrated. As the label implies,source ID field 34 includes information that identifies the packetsource. For example, referring again to FIG. 1, where HMI S1 generates apacket, the information in field 34 identifies HMI S1 as the source ofthe packet. Similarly, where source S2 generates a packet, field 34identifies source S2 as the source of the packet.

IP destination address field 36 includes an address corresponding to adestination device for the IP packet where the destination device is atthe edge of the IP network. Here, IP destination devices can only bedevices that are directly linked to the IP network and that are capableof receiving IP packets. For example, referring again to FIG. 1, anexemplary IP target device linked to network 26 may include device D4,device DN+1 or PLC1 while devices D1, D5, etc., that are not directlylinked to the IP network 26 are not capable of being IP target devices.

Referring still to FIG. 2, IP data field 49 is where data for deliveryto a destination address is typically located. In the present case, anon-IP data packet is encapsulated in field 49 where the packet includesnon-IP path device address fields 38, 40, 42 and 44 and a non-IP datafield 46. The non-IP address fields 38, 40, 42 and 44 specify a stringof addresses corresponding to non-IP devices and specify a path fornon-IP routing. Data field 46 includes information that is to bedelivered to the control device associated with the address specified inthe last non-IP address field (e.g., field 44) of packet 32.

Referring still to FIGS. 1 and 2, an exemplary data packet 32 will bedescribed in the context of a case where a user logs on to HMI S1 andperforms some activity that requires HMI S1 to transmit data to deviceDN. For instance, where device DN is a temperature sensor, the HMI S1user may use HMI browser software to request the current temperaturereading of sensor DN which causes HMI S1 to transmit a temperature readrequest to device DN.

Once HMI activity requires data transmission to device DN, an HMI S1processor generates an information packet like packet 32 in FIG. 2 thatidentifies HMI S1 as the source in field 34. In addition, in at leastsome cases, the packet will include the address of automated device D4in the IP destination address field 36 and will include the addresses ofdevices D5 and D6 through DN in non-IP path address fields 38, 40, 42and 44. The data to be delivered to device DN to facilitate access(e.g., to facilitate a temperature read in the above example) is storedin field 46. Here, when the exemplary packet 32 is transmitted by HMIS1, IP network 26 identifies the IP destination address in field 36 anddelivers the packet to device D4. When device D4 receives the packet,device D4 decapsulates the packet to identify the address of the nextdevice in the path leading to device DN (i.e., identifies the addressspecified in field 38). In addition, device D4 determines the devicetype of device D5 (e.g., a ControlNet device, a DeviceNet device, etc.)Once the address in field 38 has been identified, device D4 recapsulatesthe data in fields 40, 42, 44 and 46 in a manner that is understandableby the next path device. In the present example, as illustrated, deviceD5 is a ControlNet device and therefore the protocol used to communicatefrom device D4 to device D5 is ControlNet and therefore the informationin fields 40, 42, 44, and 46 is recapsulated in a manner consistent withthe ControlNet protocol. Next, device D4 transmits the recapsulatedControlNet packet to device D5.

When device D5 receives the packet, device D5 decapsulates the packet toidentify the address specified in field 40 and also determines what typeof device is associated with the next path address. After identifyingthe address specified in field 40 and device type, device D5recapsulates the information in fields 42, 44 and 46 to form a packethaving a form consistent with the protocol used to communicate fromdevice D5 to the device specified in field 40 (see again FIG. 2). Asillustrated in FIG. 1, the DeviceNet protocol is used to communicatefrom device D5 to device D6. The recapsulated packet is transmitted todevice D6. This process of decapsulating to identify the next non-IPdevice in a path and then recapsulating and transmitting therecapsulated packet to the next non-IP device in the path continuesuntil data is received at the destination device DN.

To form a dual protocol IP and non-IP type packet like the one describedwith respect to FIG. 2, each source 27 has to have access to informationabout configuration 21 from which appropriate required paths todestination devices can be determined. Here, the configurationinformation may be downloaded to a source like HMI S1 whenever thesource is initially linked to network 26. In the alternative, the HMI S1(or any other source for that matter) may be programmed to browseconfiguration 21 and discover all devices and linkages withinconfiguration 21. Here, for instance, HMI S1 may be programmed toidentify each device within configuration 21 that is directly linked tonetwork 26 and thereafter, via dual protocol packets, cause eachidentified device to identify other devices linked thereto.

Similarly, when a new device is added to configuration 21, any one ofthe sources 27 may be programmed to identify the new device and updateconfiguration 21 information for that source or for any of the othersources 27. In this regard, to identify newly linked devices, one of thesources may be programmed to periodically pull network devices toidentify changes in configuration 21.

In at least some cases, it is contemplated that, while it may beadvantageous to allow sources 27 to access some of the industrialcontrol devices within a system 10 and perform various activities withrespect thereto, in at least some cases, it will be necessary torestrict access and activities of one or more of the sources 27. Forinstance, where HMI S1 is only used by maintenance personnel trained toanalyze data associated with devices D4, D5, D6 through DN and tocontrol those devices, it would be advantageous to restrict HMI S1 usersso that HMI S1 cannot be used to access other system 10 devices (e.g.,PLC1, devices D1, D2, etc.).

Referring again to FIG. 1, to restrict access to system devicesaccording to one aspect of the present invention, decapsulatingfirewalls, three of which are identified by numerals 28, 30 and 31, areprovided. Exemplary firewalls 28, 30 and 31 are provided within system10 to isolate subsets of the non-IP devices from sources 27. Forexample, firewall 28 is provided to isolate PLC1 as well as devices D0,D1, D2, D3 and D6 through DN from sources 27. Similarly, firewall 30isolates devices D4, D5 and D6 through DN from sources 27 while firewall31 isolates device DN+2 from sources 27. As illustrated, firewall 30 mayalso be programmed to act as a redundant firewall to isolate PLC1 anddevices D1, D2 and D3 from sources 27.

Referring still to FIG. 1, while firewalls 28 and 30 are linked directlyto IP network 26 and are outside control configuration 21, in at leastsome cases it is contemplated that firewalls may be provided within thenon-IP network or configuration 21 itself so that access to non-IPdevices isolated thereby is restricted by the firewall while access toother non-IP devices outside the firewall is not restricted by thefirewall. For example, in FIG. 1, firewall 31 between non-IP devicesDN+1 and DN+2 isolates and restricts access to device DN+2 and does notrestrict access to device DN+1. In FIG. 1, while firewall 31 is withinconfiguration 21, IP network 26 is linked directly to firewall 31 toallow server 14 and firewall 31 to communicate.

In addition, it is also contemplated that multiple levels of firewallscould be interspersed within the non-IP network to provide differentlevels of access restriction. Thus, for instance, although notillustrated, referring to FIG. 1, another firewall could be positionedbetween devices D5 and D6 to further restrict access to devices D6through DN.

Referring once again to FIG. 1, security subsystem 25 includes asecurity/configuration server 14 that is linked to an HMI (e.g., apersonal computer) 16 and a database 24. In addition, server 14 islinked to IP network 26. Among other databases, database 24 includes anaccess control (AC) database which, as the label implies, includes rulesthat establish which industrial control devices within configuration 21can be accessed via each source 27.

Referring now to FIG. 3, an exemplary simplified AC database 50 isillustrated. Database 50 includes a source column 52 and a device accesscolumn 54. Source column 52 lists each one of the sources 27 in FIG. 1,and therefore, includes sources 51, S2 and S3 through SN. Device accesscolumn 54, as the label implies, lists a subset of the control devicesfor each one of the sources in column 52 where the list of devicesindicates the devices that may be accessed by the associated source incolumn 52. For example, for HMI S1 in column 52, access column 54 listsdevices D4, D5, D6 through DN. As another example, for source S2, accesscolumn 54 includes an entry “All DN” which indicates that source S2 canaccess all control devices within configuration 21.

Referring now to FIG. 4, an exemplary access restricting method 62according to at least some of the aspects of the present invention isillustrated where non-IP network access is restricted as a function ofsource device as well as destination device. Referring also to FIGS. 1and 3, prior to beginning method 62, it is assumed that an accesscontrol database 50 that specifies source and device access authority isstored in database 24 and that decapsulating firewalls 28, 30 and 31have been provided. Referring also to FIG. 2, at block 68, herein it isassumed that a user of HMI S1 performs an activity that causes HMI S1 toencapsulate and transmit a dual protocol data packet 32 includingencapsulated destination address information where the ultimatedestination device is device DN. Thus, here, the data packet assembledby HMI S1 identifies source S1 in field 34 and the addresses of devicesD4, D5 and D6 through DN in fields 36, 38, 40, 42 and 44, respectively.Data to be delivered to device DN is stored in data field 46.

Referring to FIGS. 1 through 4, at block 70, prior to the packet 32being received at device D4, the packet is intercepted at firewall 30.At block 72, firewall 30 decapsulates the received packet and identifiesthe device addresses in each of fields 36, 38, 40, 42 and 44 as well asthe source S1 specified in field 34. Next, at block 74, firewall 30accesses the access control database 50. At block 76, firewall 30 usesaccess control database 50 to determine if HMI S1 has authority toaccess the designated destination device DN. At decision block 78, whereHMI S1 has authority to access designated destination device DN, controlpasses to block 80 where firewall 30 transmits the data packet to the IPtarget address specified in field 36. In the present example, the IPtarget address designates device D4 and therefore, at block 80, thepacket is transmitted to device D4. Referring again to FIG. 1, after thepacket is received by device D4, routing consistent with non-IP networkprocedures continues until the packet data is delivered to thedesignated destination device DN.

Referring once again to block 78, were HMI S1 is not authorized toaccess designated destination device DN, control passes to block 82where firewall 30 performs a secondary security function. After each ofblocks 80 and 82, control passes back up to block 68 and the process isrepeated for the next encapsulated and transmitted dual protocol datapacket.

Referring to FIG. 5, a secondary security function 56 that may besubstituted for block 82 in FIG. 4 is illustrated. To this end,referring also to FIG. 4, after block 78, if HMI S1 is not authorized toaccess destination device DN, control passes to block 56 where firewall30 transmits a message to HMI S1 indicating that the HMI S1 has no rightto access destination device DN. After block 56, control passes back toblock 68 and the method described above with respect to FIG. 4continues.

Referring to FIG. 6, another exemplary secondary security function 58that may be substituted for block 82 in FIG. 4 is illustrated. Referringalso to FIG. 4, if the HMI S1 is not authorized to access destinationdevice DN, control passes from block 78 to block 58 where firewall 30generates a log or archive that reflects the communication attempt.Referring also to FIG. 1, the log is recorded in an audit/archivedatabase which forms part of database 24. An exemplary log may identifyvarious types of information about the attempted access including thesource used to attempt access, information identifying the data from thepacket, information identifying the path specified by the packet, thetime at which the attempted access occurred, where more than one attemptto access occurs, the number of attempts, etc. After block 58, controlagain passes to block 68 in FIG. 4 where the process described abovecontinues.

Referring to FIG. 7, one other secondary security function 60 that maybe substituted for block 82 in FIG. 4 as illustrated. Referring also toFIG. 4, if the source is not authorized to access the designateddestination device, control passes to block 60 where firewall 30generates a warning signal indicating an unauthorized access attempt.Here, the warning may be transmitted directly to security/configurationserver 14 so that security or other administrative type personnel candetermine if any action should be taken in response to the unauthorizedaccess attempt.

In at least some cases, two or more of the secondary security functionsdescribed above with respect to FIGS. 5 through 7 may be performed whenunauthorized access is attempted. For instance, in at least some cases,it is contemplated that a firewall 30 will generate a log ofunauthorized access attempt as well as generate a warning indicating anunauthorized access attempt. Similarly, in other cases, the firewall maytransmit a message to a source indicating no right to access adestination device, generate a log and generate a warning. Othersecondary security functions are contemplated.

While an embodiment that has been described above wherein a firewallidentifies a final destination device specified by a non-IP packet andrestricts transmission past the firewall as a function thereof, itshould be appreciated that similar systems are contemplated wherein thefirewall may be programmed instead to identify all devices correspondingto addresses in the transmission path specified by the no-IP packet andmay restrict further transmission when the source is not authorized toaccess any one or more of the those devices. For example, referringagain to FIG. 1, where HMI S1 is not authorized to access device D5 butis authorized access each of devices D4 and D6 through DN, when firewall30 receives a data packet from HMI S1 that specifies a path throughdevices D4, D5 and D6 through DN, firewall 30 would identify each ofdevices D4, D5 and D6 through DN in the packet and would halttransmission past the firewall 30 because HMI S1 is not authorized toaccess device D5.

In at least some embodiments where HMIs such as HMI S1 are usable bysystem users to access industrial control devices, it is contemplatedthat access may be restricted as a function of user identity. Forexample, a first user U1 using HMI S1 may be restricted to accessingonly a first subset of the control devices including devices D1, D2, D5,D6, D7 and so on, while a second user U2 is restricted to accessing onlya second subset of the devices including devices D1, D2, D8, D90, D101,D129, etc., despite the fact that each of users U1 and U2 uses the sameHMI S1 at different times.

Referring once again to FIG. 3, in addition to listing sources S1, S2,etc., column 52 also lists separate user identifiers U1, U2, U3, etc.For each user identifier in column 52, device access column 54 lists asubset of the control devices and components accessible by the specificuser. For example, for the user associated with user identifier U1,accessible devices include devices D1, D2, D5, D6, etc., whileaccessible devices by the user associated with identifier U2 includedevices D1, D2, D8, D90, D101, etc.

In order to restrict device and component access as a function of useridentity, user identity has to be determined. In at least someembodiments, it is contemplated that security/configuration server 14may be programmed to identify a user's identity whenever a userinitially attempts to communicate via network 26 and prior to anyattempts to access control devices. To this end, server 14 may beprogrammed to provide a log on agent 22 via HMI S1 which requires a username and password, uses biometric (e.g., fingers print scan, iris scan,voice recognition, etc.) techniques, etc., to positively identify auser. Here, after server 14 positively identifies a user, server 14 maybe programmed to associate the user with the specific HMI used by theuser during the user identifying process. For example, where the useruses HMI S1 during the identifying process and to link to IP network 26,server 14 associates HMI S1 with the specific user's identity. Theassociated source and user data is stored in an HMI/user database thatforms part of database 24 (see again FIG. 1).

An exemplary HMI/user database 120 is illustrated in FIG. 8 and includesan HMI column 122 and a current user column 124. As the label implies,HMI column 122 lists each of the HMI sources currently being used withsystem 10. Column 124 lists a current user of each of the HMIs in column122. For example, column 124 indicates that user U1 is currently usingHMI S1, that user U101 is currently using HMI S3, and so on.

Referring once again to FIGS. 1 and 2, after a user has been associatedwith an HMI in the HMI/user database, when one of the firewalls (e.g.,30) receives an information packet 32, the firewall 30 can identify thesource of the packet in field 34 and can then access HMI/user database120 (see again FIG. 8) to identify the current user of the HMI.Thereafter, the firewall 30 can access control database 50 to identifythe subset of control devices and components that are accessible by theidentified user and can restrict access to the devices when appropriate.

Referring now to FIG. 9, an exemplary method 90 for restricting accessto control devices as a function of user identity is illustrated. Hereagain, it is assumed that appropriate firewalls have been provided andthat an access control database akin to database 50 in FIG. 3 has beenstored in database 24. Referring also to FIGS. 1, 2, 3 and 8, at block94, server 14 interrogates a user via HMI S1 to identify the user'sidentity. At block 96, server 14 correlates and stores the user identitywith the HMI identifier S1 in the HMI/user database when the user logsonto IP network 26 successfully. At block 98, the user performs someactivity causing HMI S1 to attempt to access one of the control devicesvia encapsulating and transmitting a dual protocol packet at block 98.For the purposes of this explanation, it will be assumed that the usersactivities caused HMI S1 to attempt to access device DN. At block 100,firewall 30 intercepts the packet and at block 102, firewall 30decapsulates the received packet to identify the path and destinationdevice information as well as the source of the data packet (i.e., whichHMI transmitted the packet). In the present example, the firewall 30identifies HMI S1 as the source of the packet. At block 104, firewall 30accesses the stored HMI/user database and identifies the user currentlyassociated with HMI S1. In the present example, fire wall 30 identifiesuser U1 at block 104.

Continuing, at block 106, firewall 30 accesses access control database50 (see again FIG. 3). At block 108, firewall 30 uses database 50 todetermine if user U1 has authority to access designated target DN. Atblock 110, where the user U1 does not have authority to access thedesignated target, control passes to block 114 where a secondarysecurity function is performed. Here, the secondary security functionmay be any of the functions described above with respect to FIG. 5, 6 or7, may be a subset of those functions or may be any other suitablesecurity function. After for block 114, control passes back up to block98 where the process described above is repeated.

Referring again to block 110, where user U1 has authority to access thedesignated target, control passes to block 112 where the data packet istransmitted to the destination device. After block 112, control passesback up to block 98 where the process described above is repeated.

Although not illustrated, in other cases it is contemplated that theuser identifying subprocess (e.g., requiring entry of a user name andpassword, biometric analysis, etc.) may be performed by each of thedecapsulating firewalls 28, 30, 31, etc. Here, for instance, when a datapacket 32 (see again FIG. 2) is received by a firewall, such as firewall30, firewall 30 may be programmed to identify the packet source in field34 and perform an interrogation of the user currently employing thesource prior to decapsulating the other portions of the data packet. Inthis case, if user identity is successfully verified, the firewall maybe programmed to store correlated HMI/user information in a HMI/userdatabase 120 like the one illustrated in FIG. 8 for subsequent use untilthe HMI (e.g., S1) and user association is discontinued. For instance,when an HMI user logs off an HMI the HMI/user association may be broke.As another example, if a certain period of time (e.g., 30 minutes)without HMI activity occurs, the HMI/user association may be broke.

In addition to restricting device and component access as a function ofuser identity, in at least some embodiments it is contemplated thataccess may be restricted in other ways as well. For example, in at leastsome cases, it may be advantageous to restrict access to specificcontrol devices so that access can only occur during specific times,such as during normal first shift business hours of 9:00 A.M. to 4:00P.M. or during normal maintenance hours, such as between 10:00 A.M. and11:00 A.M. In other cases, it may be desirable to restrict access as afunction of the location of a source attempting to access a device orcomponent. For example, in at least some cases, while it may bedesirable to allow HMI users inside a facility to access controldevices, persons outside a manufacturing facility often should not beable to access control devices within the facility. Referring again toFIG. 1, when HMI S1 is used in an attempt to access configuration 21devices from a location outside a facility associated with configuration21, access should be restricted while, when HMI S1 is within thefacility, a lesser amount of restriction may be appropriate.

As another example, with certain types of devices and components, it maybe desirable to restrict access thereto such that, the devices andcomponents can only be accessed when an HMI to be used to access thedevices is in a position in which the user of the HMI has the ability toclearly view how the devices are operating. Here, separate zones withina facility may be specified and associated with specific devices suchthat access to the devices and components via an HMI (e.g., S1) is onlyallowed when the HMI S1 is located within the associated zone. Toidentify HMI location any of several different systems can be employed.For example, where HMI S1 has to be physically linked via hardwire tonetwork 26, location can be determined by identifying the location ofthe linkage. In other cases where HMI S1 is equipped for wirelesscommunication within a facility or outside the facility, access pointsor the like can be used to generate data usable through a triangulationor other type procedure to identify the location of HMI S1. Methods forusing wireless signals to identify HMI location are well known andtherefore are not described herein detail.

In addition to separately using user identity, time, location and othernon-packet characteristics to restrict device and component access,subsets of those non-packet characteristics can be used to restrictaccess. For example, user U1 may be restricted such that user U1 canonly access device D2 between 10:00 A.M. and 11:00 A.M., but during thattime, may be able to access device D2 from any location while user U2 isrestricted such that user U2 can access device D2 between 9:00 A.M. and4:00 P.M. but can only access device D2 during that time period when anHMI used by user U2 is within a first zone (i.e., zone 1) within thefacility. Other combinations of non-packet characteristics on which torestrict access are contemplated.

Moreover, in at least some cases access to certain devices could berestricted as a function of non-user and non-source non-packetcharacteristics such as time, source location, etc. For instance, when asource is located outside a facility associated with configuration 21,irrespective of which source is used to attempt access or, in the caseof an HMI, which user is using the HMI, access may be prohibited.Similarly, access may also be prohibited to certain devices during hoursoutside a normal business day irrespective of source or HMI useridentity.

Referring now to FIG. 10, an exemplary relatively more detailed accesscontrol database 126 is illustrated which includes, among other columns,a user column 128, a device access column 130, a time column 132 and alocation column 134. User column 128 lists the users U1, U2, etc. thatare authorized to access system 10 for any purpose. Access column 130lists a subset of configuration 21 devices for each one of the users incolumn 128 that are accessible by the user. For example, for user U1,column 130 lists devices D1, D2, D5, D6, etc.

Referring still to FIG. 10, time column 132 specifies a period for eachcombination of a user and one of the devices or a subset of the deviceslisted in column 130. For example, for the combination of user U1 anddevice D1, column 132 lists a time period between 9:00 A.M. and 4:00P.M. which means that user U1 can access device D1 during the periodbetween 9:00 A.M. and 4:00 P.M. Similarly, for the combination includinguser U1 and device D2, column 132 lists the time period between times10:00 A.M. and 11:00 A.M. which indicates that user U1 can access deviceD2 during the one hour between 10:00 and 11:00 A.M. An “All” designationin column 132 indicates that an associated user in column 128 can accessan associated device in column 130 at any time.

Referring yet again to FIG. 10, location column 134 lists locationrestrictions for each use-device combination in columns 128 and 130. Forexample, for the combination including user U1 and either of devices D5or D6, location column 134 indicates that the devices D5 and D6 can onlybe accessed by user U1 when an HMI used by user U1 is located within aZone 7 within a facility. An “All” designation in column 134 indicatesthat access can be had from any location in which an HMI is linkable toIP network 26.

While database 126 is more complicated than the previously describedaccess control database 50 illustrated in FIG. 3, it should beappreciated that operation of firewalls in a manner consistent withdatabase 126 is similar to operation using simple database 50. To thisend, referring again to FIGS. 1 and 9, process 90 in FIG. 9 performed byserver 14 and the firewalls would be similar to the process describedabove except that at blocks 106 through 110, a firewall would use theadditional non-packet information or characteristics in database 126 todetermine whether or not the user has authority to access the designatedtarget device or component. For instance, where firewall 30 identifiesuser U1 at block 104 and the designated destination device is D5, atblock 108, firewall 30 determines that access by user U1 to device D5can only occur between 9:00 A.M. and 4:00 P.M. and can only occur whenthe HMI used by user U1 is within Zone 7. Firewall 30 can identify thecurrent time and compare it to the required period and can obtain HMIlocation information from a device tracking system (not illustrated) andcompare that information to the boundaries that define Zone 7. Where theuser's HMI is within Zone 7 and the current time is between 9:00 A.M.and 4:00 P.M., user U1 is authorized to access device D5 and controlpasses to block 112. Where the HMI is not located in Zone 7 or thecurrent time is not within the time period 9:00 A.M. to 4:00 P.M.,control passes to block 114 where a secondary security function isperformed.

One other way to restrict device and component access is to restrict theaccess as a function of employee type or training of a particular usertype. For example, many facilities may employ maintenance engineerscommissioning engineers, industrial engineers, plant managers, lineoperators, operators of specific line types, etc. While each of thesetypes of employees likely will require access to some control devices toperform their jobs, in most cases, the subsets of devices that need tobe accessed by the different employees will be different. Here, it iscontemplated that different job titles that reflect user types may beassigned to each system 10 user and that different access rights may beprovided as a function of the user type. For instance, a maintenanceengineer may be authorized to access a first subset of control deviceswhile a line operator may be authorized to access a second subset ofcontrol devices. In this case, when a firewall 30 receives a packet anduses packet information to identify the user of the HMI (e.g., laptopS1) used to transmit the packet, the firewall may further be programmedto identify the job title associated with the user and thereafter toidentify the subset of devices and components accessible by the specificuser.

Referring now to FIG. 11, an exemplary access control database 140usable to control device and component access as a function of user typeis illustrated. Database 140 includes a type-device access section 142and a user type section 150. Section 142 includes a user type column 146and an access column 148. User type column 146 lists user types for eachof the different types of employees that may require access to anycontrol devices with configuration 21. For example, in FIG. 11, usertypes include a maintenance engineer, a commissioning engineer, a plantmanager, a line 3 operator, etc. Access column 148 lists a subset ofdevices accessible by each one of the user types in column 146. Forexample, devices D4, D5, D6, etc. are listed for the maintenanceengineer designation in column 146 while devices D1, D2, D8, D90, etc.are listed for the commissioning engineer designation in column 146.

Referring still to FIG. 11, user type section 150 includes a user column152 and a type column 144. Each of the system 10 users authorized toaccess at least one control device is listed in column 152. For example,users U1 and U2 as well as other users are listed in column 152. Typecolumn 144 lists a user type for each one of the users in column 152.For example, the user type “maintenance engineer” has been assigned toeach of users U1 and U2 in column 152 while type “commissioningengineer” has been assigned to user U3 in column 152.

Referring still to FIG. 11 and also to FIGS. 1 and 9, to restrict accessas a function job titles or user types, after a firewall has identifiedthe identity of a user that caused an HMI to transmit a packetintercepted thereby at block 104, at block 108, the firewall usesdatabase 140 to determine whether or not the user has authority toaccess the designated destination device. To this end, the firewallfirst uses user characteristics section 150 of database 140 to determinethe type of user (e.g., maintenance engineer, commissioning engineer,plant manager, etc.). Assuming that user U1 caused the packet to betransmitted, the firewall uses section 150 to determine that user U1 isa maintenance engineer. Next, after identifying the user type, thefirewall uses database section 142 to identify devices that the user isauthorized to access and restricts as a function of the device list incolumn 148.

In most cases essential control method and processes in an industrialenvironment will be supported entirely by control components and deviceslinked via the non-IP network and within configuration 21. Here, toensure that essential methods and processes are always performed asquickly as possible, and in at least some cases, it is contemplatedthat, when the firewalls intercept data packets, the firewalls will beprogrammed to prioritize packets transmitted thereby onto the non-IPnetwork. In this regard, referring to FIG. 10, access control database126 includes a priority column 136 where priority column 136 listsdifferent priorities for each one of the user and device combinations incolumns 128 and 130. For instance, a priority P3 is listed in column 136for the combination including user U1 and device D1 while a priority P1is provided in column 136 for the combination including user U1 anddevice D5 in columns 128 and 130, respectively, where priority P1 is ahigher priority than priority P3. In this case, it is contemplated thatnon-IP network communications all have assigned priority values so thatwhen a firewall (e.g., see 30 in FIG. 1) transmits a packet, thepriority assigned to the packet by the firewall can be compared to thepriorities of non-IP network packets and can be routed accordingly.

Referring now to FIG. 12, an exemplary sub-process 250 that may besubstituted for block 112 in FIG. 9 is illustrated. Referring also toFIGS. 1 and 9, after a firewall determines that a user has authority toaccess a designated destination device, control passes from block 110 toblock 252 where firewall 20 accesses the priority data in database 126(see again FIG. 10). The firewall uses the priority data in column 136to identify the priority of a packet having the non-packetcharacteristics associated therewith listed in columns 128, 130, 132 and134. After priority has been identified, at block 256, the firewalltransmits the packet to the destination device or component in a mannerconsistent with the priority data.

In many cases, while it may be desirable to allow a specific user toaccess specific devices and components for specific purposes, it may notbe desired to allow the user to access the devices and components forother purposes (e.g., to facilitate other applications). For example,while it may be desirable to allow a plant manager to monitor virtuallyany device activity within a facility, it may be undesirable to allow aplant manager to alter or control device operations. Thus, according toanother aspect of at least some embodiments of the present invention,device access may be limited or restricted on an application byapplication basis. In this regarding, referring once again to FIG. 10,an applications column 135 is provided within database 126 whereapplications columns 135 lists separate applications for each one of theuser and device combinations in columns 128 and 130, respectively. Forinstance, for the combination including user U1 and device D1 in columns128 and 130, column 135 lists applications A1, A3 and A4 meaning thatonly applications A1, A3 and A4 can be affected by user U1 on device D1.In other words, applications A2 and applications A5, A6 and so on cannot be performed by user U1 on device D1.

In many cases, when a user causes an HMI to access a device by sendingdata packets, it is impossible to determine the application to beperformed via the device from a single packet. Thus, in at least someembodiments, it is contemplated that the firewalls will be programmed toaccumulate information packets intercepted thereby until intendedapplications associated with the accumulated packets can be identifiedfrom the packet information. For instance, in one simple case, afirewall may have to accumulate 100 information packets in order toidentify a specific type of application to be affected by theaccumulated packets. Here, the firewall would store the packetinformation until sufficient information is available to identify theintended application. Once the intended application is identified, thefirewall accesses database 126 and determines whether or not theintended application is authorized (e.g., whether or not the applicationappears in the listing in column 135 corresponding to the user anddevice combination in columns 128 and 130, respectively).

Referring now to FIG. 13, a sub-method 270 that may be substituted forblocks 102, 104, 106, 108 and 110 in FIG. 9 is illustrated. Referringalso to FIGS. 1 and 9, after a firewall intercepts an data packet atblock 100, control passes to block 272 in FIG. 13. At block 272, thefirewall decapsulates the received data packet to access targetinformation, packet data and the packet source (e.g., to identify theHMI that transmitted the packet). At block 274, the firewall accessesthe stored HMI/user database and identifies the HMI user. At block 276,the firewall accesses the access control database 126 (see again FIG.10). At block 278, the firewall uses the packet data to attempt toidentify the intended application to be performed on the target device.At block 280, where the data from the packet and data from otherpreceding packets is insufficient to identify the application, controlpasses to block 282 where the packet information is stored. At block284, the firewall receives next data packet and control passes back upto block 272 where the decapsulating and analysis process is repeated asdescribed above.

Referring again to block 280, if the intended application has beenidentified, control passes from block 280 to block 286. At block 286,the firewall uses the access control database 126 to determine if theuser has authority to access the designated destination device and toaffect the intended application. At block 288 where the user hasauthority to access and to affect the intended application, controlpasses to block 112 in FIG. 9 where all of the stored packet informationis transmitted to the destination device. However, at block 288, wherethe user does not have the authority to access the device or does nothave the authority to affect the intended application, control passesback to block 114 in FIG. 9 where a secondary function is performed.

According to one additional aspect of the present invention, in at leastsome embodiments, it is contemplated that security server 14 (see againFIG. 1) may be useable in a learn mode or during a learning process tomonitor use of an HMI by a particular user type to identify expectedcontrol device access for that user type so that the security server 14can establish access control rules for populating an access controldatabase. In this regard, in at least some cases it is contemplated thatprior to a learning procedure for a specific user type, no restrictionshave been specified in an access control database for restricting useraccess to the industrial control devices in configuration 21. Here,during the learning process an HMI user of the type associated with thespecific process performs various tasks required to perform his job.During task performance the user's HMI forms and transmits data packetson IP network 26 that designate destination devices within configuration21. Whenever one of the firewalls 28, 30, 31, etc., receives a datapacket from the HMI, the firewall passes the packet on to thedestination device without restriction.

Security server 14 is programmed to monitor communications between theHMI and the configuration 21 devices and store records of device access.In this regard, the firewalls 28, 30, 31, etc., may cooperate totransmit copies of information packets from HMIs currently being trackedby server 14 to server 14 so that server 14 can store records of deviceaccess. In addition to storing records identifying that access hasoccurred, the server 14 may also identify and store other non-packetcharacteristics such as the times at which the access occurs, thelocations of the HMI when access occurs, the frequency of access, etc.Moreover, server 14 may also be programmed to identify the nature of theaccess performed by an HMI during a learning process. For example,server 14 may be programmed to determine whether or not the access wasassociated with a monitoring activity, a value setting or controlactivity, a data exchange or some other type of activity. After alearning process has been completed, server 14 can use the stored accessinformation to populate a portion of an access control database likedatabase 50 in FIG. 3 in a simple case or, to populate a more complexcontrol database like database 126 in FIG. 10 or database 140 in FIG.11.

Referring now to FIG. 14, an exemplary learning process 230 isillustrated. At block 232, a system administrator uses HMI 16 to placesecurity server 14 in a learning mode so that server 14 can identifyaccess typically required of a specific user type. Next, at block 234,the administrator uses HMI 16 to specify a specific user type and tospecify an HMI to be tracked. For example, at block 234, theadministrator may indicate that the current learning procedure will beused identify access activity required by a maintenance engineer and mayspecify HMI S1 as the HMI to be tracked during the learning process.Hereinafter it will be assumed that the learning process is for amaintenance engineer type user and that HMI S1 is to be tracked duringthe learning process.

Continuing, referring to FIG. 14, at block 236, while a maintenanceengineer uses HMI S1 to perform routine maintenance activities on theconfiguration 21 control devices, server 14 tracks device access by HMIS1. At block 238, server 14 stores HMI S1 access information. At block240, server 14 monitors for some indication that the learning processshould be ended (e.g., a learn process complete signal from HMI 16). Atblock 242, while the learning process continues, control loops back upto block 236 where the process including blocks 236, 238 and 240 isrepeated. At block 242, when a system administrator uses HMI 16 toindicate that the learning process has been completed, control passes toblock 244 where server 14 updates the access control database. In thepresent example, the changes to the access control database may resultin supplementing a type/device access section 142 of an access controldatabase as illustrated in FIG. 11 where device access indicates devicesaccessed via HMI S1 during the learning process.

While the learning process has been described above in the context of amethod for identifying access required by a specific user type, itshould be appreciated that a similar process could be performed for asystem user type, the administrator identifies a specific user at thebeginning of the learning process.

According to one other aspect of at least some embodiments of thepresent invention, it is contemplated that HMI 16 may also be used by asystem administrator to manually specify access control information. Inthis regard, server 14 may be provided with a full specification relatedto the industrial control devices that form configuration 21 so thatinformation related to configuration 21 can be provided via HMI 16allowing the administrator to manually select devices or subsets of thedevices to be accessible by specific system users, specific sources(e.g., specific laptops, specific servers and databases, etc.), and,where contemplated, to specify other non-packet characteristics toaffect access restriction. Here, the configuration 21 informationpresented via HMI 16 may take any of several different forms including,but not limited to, a hierarchical list of control devices, a graphicview of the control devices such as a tree, an iconic graphical view,etc.

Referring now to FIGS. 1 and 15, an exemplary administrator's HMIscreenshot 180 that may be presented via HMI 16 during manual accesscontrol specification is illustrated. Window 180 includes instructions182 to guide an administrator to provide information required to provideaccess control information. In addition, window 180 includes asub-window 184 in which a configuration graphic consistent withconfiguration 21 in FIG. 1 is presented where each control device withinconfiguration 21 is separately presented and linking relationshipstherebetween are also shown. Moreover, a mouse controllable selectionicon 194 is provided that can be moved within sub-window 184 to point todifferent control devices therein. When icon 194 is pointing at one ofthe device icons within sub-window 184, a selection activity (e.g., adouble click on a controlling mouse) causes the device icon to behighlighted. In FIG. 15, each of devices D4 and D5 are shown as beinghighlighted via cross-hatches therethrough.

Referring still to FIG. 15, a double arrow icon 181 is provided adjacenta user indicator field 195 which, in FIG. 15, indicates user U1. Here itis contemplated that icon 181 may be used to scroll through differentknown system users for which access control information has already beenplaced in the access control database so that the administrator caneasily switch from one user to the next during a specifying procedure.Where access control information has already been stored for one of theusers, when the administrator scrolls to that user's identity via icon181, in at least some cases, it is contemplated that a graphic ofconfiguration 21 for the specific user would automatically be providedwithin sub-window 184 and would indicate, via highlighting, devicescontrollable by a particular user. For new users, the administrator cansimply provide an identifier (e.g., U1) in field 195 corresponding tothe new user. Referring again to FIG. 15, window 180 also includes anenter icon 186. After device icons to be accessible by a specific userhave been selected via sub-window 184, when enter icon 186 is selected,in at least some cases, a simple access control database like database50 in FIG. 3 is supplemented for the specific user.

In other cases, where additional non-packet characteristics are to beused to restrict device access, when enter icon 186 is selected in FIG.15, other specifying tools may be provided via interface 16. Forexample, in at least some cases, when icon 186 is selected in FIG. 15,another HMI window like window 200 in FIG. 16 may be provided. In FIG.16, additional instructions 202 are provided for a system administratorto guide the administrator in specifying other important non-packetcharacteristics for restricting access. In the present example, theinstructions indicate that for the devices D4 and D5 that were selectedvia sub-window 184 in FIG. 15, the administrator should indicate accesstimes and specify required locations for the specific user to access. Inaddition, for each of devices D4 and D5, a separate non-packetcharacteristics specifying window 217 and 221, respectively, isprovided. Each of windows 217 and 221 is similar and therefore, in theinterest of simplifying this explanation, only aspects of window 217corresponding to device D4 will be described here. Within window 217,start and stop time fields 219 and 218, respectively, are provided thatcan be used by the administrator to specify start and stop times at thebeginning and end of a period during which the particular user should beable to access device D4, respectively. In addition, two headed arrowicons are provided in each of the time fields 219 and 218, only one ofthe two headed arrow icons 215 labeled. The two headed arrow icons maybe selected via mouse controlled cursor 208 to change the correspondingstart or stop time.

Referring still to FIG. 16, window 217 also includes a locationrestriction sub-window 223 that can be used to specify locations inwhich the particular user should be able to access device D4. Withinsub-window 223, a list of possible location restricting spaces isprovided including an “All” designation, a Zone 1 designation, a Zone 2designation, etc. Cursor 208 can be used to select one of the locationrestriction designations. A selection box 225 is provided around theselected location restriction designation. For example, in FIG. 16, box225 is provided around the All designation indicating that, as currentlyset, the user should be able to access device D4 from all locations. Adouble headed arrow icon 227 is provided within window 223 to allow theadministrator to scroll through location restriction designations wheremore than the four illustrated designations are possible.

Referring still to FIG. 16, window 200 also includes an enter icon 204and a double headed arrow icon 206 near a lower edge thereof. Doubleheaded arrow icon 206 can be used to scroll through different devicewindows like windows 217 and 221 when more than two devices are selectedvia sub-window 184 in FIG. 15. After time and location restrictioninformation has been specified via windows 217 and 221, when enter icon204 is selected, server 14 compiles the information specified viawindows 180 and 200 and supplements an access control database similarto the database illustrated in FIG. 10.

Referring now to FIG. 17, a method or process 160 for manuallyconfiguring an access control database using an administrator's HMI isillustrated. At block 162 a control configuration specification (e.g., agraphical specification or a directory view type specification) isprovided. At block 166, an administrator's interface 16 is provided. Atblock 170, device selection tools and non-packet characteristics settingtools where necessary, like tools illustrated in FIG. 15 or 16 or toolsakin thereto, are provided via HMI 16. At block 172, after theadministrator uses the HMI tools to specify access control information,the access restriction information is provided to server 14 which, atblock 174, updates the access control database.

While two different methods for specifying access control databaseinformation are described above, one in which the security serverperforms a learning process and another in which a system administratormanually specifies access control information, in at least some cases itis contemplated that a hybrid system may be provided wherein, during alearning process, the server 14 performs a process similar to theprocess described above. Thereafter, an administrator may use interfacetools like those described above with respect to FIGS. 15 and 16 toanalyze the access control information that resulted from the learningprocess and to modify that access information. To this end, for example,referring again to FIG. 15, after a learning process for user U1, theadministrator may access a screen shot like the one illustrated in FIG.15 for user U1 where all accessed devices are shown as highlighted.Here, the administrator may either move on to a screen like that shownin FIG. 16 to see the non-packet characteristics that resulted from thelearning process or may manually select other devices via sub-window 184to be accessible or deselect highlighted devices in sub-window 184 thatshould not be accessible.

What has been described above includes examples of the presentinvention. It is, of course, not possible to describe every conceivablecombination of components or methodologies for purposes of describingthe present invention, but one of ordinary skill in the art mayrecognize that many further combinations and permutations of the presentinvention are possible. Accordingly, the present invention is intendedto embrace all such alterations, modifications, and variations that fallwithin the spirit and scope of the appended claims.

For example, while access control information is described above asindicating devices that can be accessed and non-packet characteristicsthat correspond to access rights, in other embodiment the access controlinformation may instead identify devices that cannot be accessed ornon-packet characteristics that correspond to inaccessible conditions.For instances, referring again to FIG. 3, for user U1, the device accesslist in column 54 may list devices D3, D8, D9, etc., that are notaccessible by user U1 and in that case the firewalls would only allowaccess to devices that are not listed in column 54. In addition,referring again to FIG. 1, while the comparing steps have been describedabove as being performed by firewalls 28, 30 and 31, in at least somecases, it should be appreciated that the comparison steps may beperformed by server 14. Moreover, while firewalls 28, 30 and 31 areillustrated as being separate devices or components within the overallsystem 10, it should be appreciated that each one of the firewalls maytake any of several different forms. For example, firewall 28 may beembedded within PLC1, may be its own standalone device or may run on aremote server.

In addition, referring again to FIG. 1, while firewalls 28 and 30 areshown as being located between sources 27 and the devices within network21, firewalls may be linked to the other components described in any ofseveral ways and the devices and sources may be programmed tocommunicate accordingly. For instance, in at least some applicationsfirewalls 28 and 30 may be programmed to physically intercept anycommunications transmitted to destination devices within network 21 evenif those communications do not specify one of the firewalls as a pathdevice. Thus, for example, where source S1 is used to transmit a packetidentifying the address of PLC1 as the IP destination (see field 36 inFIG. 2), fire wall 28 may be programmed to monitor network 26 for allcommunications specifying PLC1 as an IP address and to then interceptthose communications to be scrutinized as described above.

As another instance, firewalls (e.g., 28, 30) may be employed andreferenced as network devices that separate network 21 from sources 27.Here, firewalls 28 and 30 may be placed within the overall network sothat the firewalls physically separate network 21 from sources 27. Inthis case, when a source is used to access/control one of the deviceswithin network 21, the source may be programmed to route a data packetto one of the firewalls as if the firewall was one of the devices withinnetwork 21. In other words, referring to FIGS. 1 and 2, a packet mayspecify the address of firewall 28 in IP destination address field 36and the Non-IP path address fields 38, 40, etc., may then specify thenetwork devices PLC1, D0, D1, etc. In this case the data packets are notintercepted by the firewalls but are directed specifically to thefirewalls as part of the network 21.

Exemplary System

Now an exemplary system will be described wherein a second or embeddedprotocol that is embedded in an IP packet is the CIP protocol.

In addition to specifying a routing or communication path for packets,the CIP protocol also enables specification of specific activities thatshould be performed by a target network device. To this end, the CIPprotocol enables specification of a specific “object” associated with atarget network device that is associated with a packet as well as aservice to be performed at, by or related to the object. With respect tothe “object” concept, this concept contemplates a hierarchicalorganization of device functions and features including, in at leastsome cases, a class level, an instance level and an attributes level.For instance, an exemplary class may include a general class of devicessuch as proximity sensors. An instance of a proximity sensor, as thelabel implies, is a single occurrence of a proximity sensor. Forexample, in at least some cases a single network device may includethree instances of the proximity sensor class (i.e., the device includesthree separate proximity sensors). Instance attributes are functional oroperational characteristics associated with either a class or aninstance of a class. For example, a proximity sensor may be able to beoperated in either one of two different ways. First, a proximity sensormay be able to precisely sense proximity of a part at a station along atransfer line and generate a variable signal to indicate a precisedistance between the sensor and the part. Second, the proximity sensormay be able to operate in a binary fashion to indicate either presenceor absence of a part at a transfer line station. Here, the mode ofsensor operation (i.e., binary or precise) may be an attribute of theproximity sensor class that can be altered. As another example, where aninstance of a proximity sensor is operated in the binary mode, anattribute of the instance may be the value (i.e., 1 or 0) of the sensorat a specific time.

In the above examples, a service to be performed on the proximity sensorclass may be to change the mode of operation from binary to preciseusing a write command. A service that may be performed on an instance ofa proximity sensor that is operating in the binary mode may be to readthe sensor value. Here, it should be appreciated that the examplesdescribed above are only exemplary and have been limited in the interestof simplifying this explanation. In a working system, as one of ordinaryskill in the art would understand, a huge number of different objectclasses, instances and attributes are contemplated and would besupported by a functioning system.

Referring again to FIG. 1, in the case of the CIP protocol, to determineif a packet from a source should be transmitted to a target ordestination device, a firewall 30 may be programmed to examine anintended routing path through the network 21 devices, the target device,the target object (i.e., class-attribute, class-instance-attribute,etc.) at a target device and perhaps the service to be performed at, byor to the target object. The process wherein a firewall examines targetobjects and services is referred to hereinafter as “object filtering”.

To support object filtering, first, objects accessible to specificsources have to be identified and services that can be initiated at, byor on specific objects. To this end, an enhanced access database may beprovided. Referring now to FIG. 28, an exemplary access control database562 that may be maintained within database 24 for supporting objectfiltering is illustrated. Exemplary database 562 includes a sourcecolumn 552, a device column 554, a class column 556, an instance column558, an attribute column 560 and a service column 564. Source column 552lists each of the sources that may, for any purpose, access deviceswithin non-IP network 21. To this end exemplary sources in column 552include sources 51, S2. Device column 554 includes a separate list ofnon-IP network devices corresponding to each of the sources in column552. For example, column 554 includes devices D1 and D2 corresponding tosource 51 in column 552. The devices associated with a source in column552 include any non-IP network devices that the corresponding source canaccess for any reason.

Referring still to FIG. 28, class, instance and attribute columns 556,558 and 560, respectively, together are used to specify different deviceobjects corresponding to each of the devices in column 554. Forinstance, the combination including class C1 and attribute A1 specifiesa specific attribute of a specific class associated with device D1.Similarly, the combination including class C1, instance 11 and attributeA4 specifies a different object associated with device D1. Other class,instance and attribute combinations are contemplated and a small subsetthereof are illustrated in columns 556, 558 and 560. As shown, more thanone attribute may be associated with a class or instance and more thanone instance may be associated with a single class.

Service column 564 specifies one or more services or functions that areassociated with each of the attributes in column 560. In the example, afirst service Ser1 is associated with attribute A1 in column 560.Similarly, two services Ser1 and Ser2 are associated with attribute A2in column 560. A service Ser22 corresponds to an object including classC1, instance 11 and attribute A4 related to device D1 and source S1 incolumns 554 and 552, respectively, which means that source S1 isauthorized to initiate service Ser22 for device D1 and the relatedobject corresponding to the combination of class C1, instance 11 andattribute A4.

In the case of the CIP protocol there are two general ways in which tosend data packets between sources and target network devices. First,when only minimal amounts of information/data need to be transmitted toa network device or from a network device to a source and there is noneed for a reply from the receiving component or when only minimal backand forth communication is necessary, data packets can be sent between asource and a network device along route paths without forming apersistent connection path therebetween. A communication of this type isreferred to hereinafter as an “unconnected send” because, as the labelimplies, a packet is sent in one direction and a persistent connectionpath is not set up between the source and device. Herein, the phrase“persistent connection path” is used to refer to a path that, onceestablished, does not have to be re-indicated each time a data packet istransmitted along the path and that can be affirmatively eliminated.

Second, when larger quantities of information need to be sent between asource and a network device or when several rounds of back and forthcommunication between a source and a network device are required, apersistent communication path can be established between the source andthe network device so that overhead required to perform communicationscan be reduced appreciably (i.e., the path does not have to bere-indicated with each transmitted packet). To establish a persistentsource to network device connection path, several communications arerequired in at least some embodiments including an initial sourcecommunication indicating that a persistent connection path should beformed and specifying a communication path through the non-IP network toa destination or target device. In addition, an initial network devicecommunication back to the source is required in some embodiments.

In at least some applications the initial source communication alsoincludes a target-to-originator (T-O) connection ID (T-O ID) that is tobe used by the target device when the target sends packets back to thesource (i.e., the originator). Here, the source will only accept packetsback from the target network device that include the T-O ID. Similarly,in at least some applications, the initial network device communicationalso includes an originator-to-target (O-T) connection ID (O-T ID) thatis to be used by the source (i.e., the originator) when the source sendssecond and subsequent packets to the target network device. Here, thetarget device only accepts packets from the source that include the O-TID. Establishment of a connection path will be described in greaterdetail below.

Hereinafter, unless indicated otherwise, the initial source packet forestablishing a persistent connection path with a network device will bereferred to as an “unconnected forward open request” because the packetcommences the opening of a connection path and is initially unconnected(i.e., the path initially is not connected). Similarly, the initialnetwork packet will be referred to hereinafter as an “unconnectedforward open reply” because the packet is a reply to the open request.Packets transmitted after a connection path is established will bereferred to hereinafter as “connected send” packets or communications. Apacket to eliminate a persistent connection path will be referred tohereinafter as an “unconnected forward close request”.

Referring to FIG. 18, an exemplary dual protocol data packet 300including a CIP data packet embedded or encapsulated within an IP datapacket is illustrated. Exemplary packet 300 corresponds to a typicalunconnected send packet. Here, packet 300 is shown in its simplifiedform and it should be appreciated that a typical packet may includeother fields populated with various types of information useful orrequired for transmitting the packet 300 from a source to a targetnetwork device.

Exemplary packet 300 is a typical IP packet and, to that end, includes aframe that specifies packet source and destination device as well as adata field within the frame. Packet 300 includes a source ID field 302and an IP destination address field 303. The IP packet data field isidentified by numeral 324 and includes fields 304, 306, etc. IP datafield 324 is where data for delivery to an IP destination address istypically located. In the present case, a non-IP data packet isencapsulated in field 324 where the packet includes non-IP path deviceaddress fields 312, 314, 316 and 318 as well as a general service typefield 304, a connection manager field 306 and a target objectpath/service field 308. As in the case of FIG. 2 above, the non-IPaddress fields 312, 314, 316 and 318 specify a string of addressescorresponding to non-IP devices and specify a path for non-IP routing tothe target network device.

Referring still to FIG. 18, general service type field 304, as the labelimplies, specifies a general type of service associated with packet 300.For example, exemplary general service types include an unconnectedsend, a connected send, an unconnected forward open request, anunconnected forward open reply, an unconnected forward close request,etc. Here, although a small number of general service types aredescribed, it should be understood that many other service types arecontemplated. In FIG. 18, as indicated in brackets, the service typeassociated with packet 300 is an unconnected send meaning that thepacket 300 is to be transmitted to a target network device withoutestablishing or opening a persistent connection path.

Connection manager field 306 is used to indicate that the packet 300should be internally routed within the IP destination device to aconnection manager object within the device. Here, in at least someembodiments, each of the non-IP network 21 devices includes a connectionmanager object which is typically a software program that is provided tomanage communication paths for the device. In the case of an IPdestination device, the connection manager object is capable ofidentifying a general service type specified in field 304 and examiningthe address fields (e.g., 312, 314, etc.) to identify the next devicewithin the non-IP routing path to which at least a subset of the packet300 information should be transmitted.

Referring still to FIG. 18, object path/service field 308, as the labelimplies, specifies a specific object associated with the target deviceand a service to be performed at, by or on the object. For instance,consistent with the above example, the object path and service field 308may specify a specific proximity sensor instance associated with atarget device and that the value of the sensor should be read (i.e., theservice is to read a value). In this regard, referring also to FIG. 19,an exemplary object path/service field 308 is illustrated that includesan object field 334 and a service field 336. Object field 334 includes aclass subfield 338, an instance subfield 340 and an attribute subfield342.

Referring now to FIG. 20, an exemplary submethod 350 that may besubstituted for a portion of the method 62 illustrated in FIG. 4 isshown where the submethod corresponds to a firewall process that may beperformed when an unconnected send data packet is intercepted where thepacket includes an embedded CIP subpacket. Referring also to FIGS. 1 and4, after a firewall (e.g., 30) intercepts a packet at block 70, controlpasses to block 352. At block 352, firewall 30 decapsulates the receivedpacket and identifies the packet source, the target device, an objectspecified in object path/service field 308 and the service specified infield 308. At block 354, firewall 30 accesses the stored AC database(see again FIG. 28). At block 356, firewall 30 uses the database todetermine if the source has authority to access the target device forany purpose. This step may comprise simply checking the list in column554 of the database 562 to see if the target device is correlated withthe source device in column 552. At decision block 358, where the sourcedoes not have authority to access the target device for at least onepurpose, control passes down to block 366 where a secondary securityfunction is performed. Here, the secondary security function may takeany of several different forms including the forms described above withrespect to FIGS. 4 through 7.

Referring still to FIGS. 1, 18 and 20, if the source has authority toaccess the target device at block 358, control passes to block 360 wherefirewall 30 uses AC database 562 to determine if the source hasauthority to commence the identified service for the identified object(i.e., object filtering). At block 362, where the source does not haveauthority to commence the identified service for the identified object,control passes to block 366. Where the source has authority to commencethe service for the object, control passes to block 364 where packetinformation is transmitted to the first device in the non-IP routingpath specified by the unconnected send packet (see address in field 312in FIG. 18). Transmission continues through the non-IP path until asubset of the data is received by the target device. The target deviceuses the subset of packet information to perform the service at, on orby the object specified in field 308.

Referring now to FIG. 21, another exemplary dual protocol packet 370including a CIP packet embedded within an IP packet is illustrated.Fields in packet 370 that are similar to fields in packet 300 describedabove with respect to FIG. 18 are labeled with identical numbers and, inthe interest of simplifying this explanation, are not described here indetail. More specifically, fields 302, 303, 306, 312, 314, 316 and 318are akin to the identically numbered fields in FIG. 18. In FIG. 12,however, the information in fields 302, 303, 312, 314, 316 and 318 isgenerally the reverse of information in the similarly numbered fields inFIG. 18 (i.e., the source ID in field 302 corresponds to the originaltarget device, the address field 303 corresponds to the original sourcedevice and the path specified by fields 312, 314, etc., is the inverseof the path specified by the similarly numbered fields in FIG. 18). Inaddition to fields 302, 303, 306, 312, 314, 316 and 318, packet 370includes a general service type field 374 and a T-O ID field 377. Field374 indicates an unconnected forward open request meaning that apersistent connection should be set up between the source and the targetdevice to facilitate subsequent communications. T-O ID field 377includes a target-to-originator connection ID that is generated by thesource.

Referring again to FIG. 1 and also to FIG. 22, in at least someembodiments it is contemplated that firewall 30 may maintain a forwardopen table 402 for keeping track of open or established connection pathsbetween sources and target network devices. To this end, exemplary table402 includes a source IP column 390, a destination IP column 392, aroute path column 394, a T-O connection ID column 396, an O-T connectionID column 398 and a connection serial number column 400. In FIG. 22,data corresponding to a single open connection path is illustrated andarranged in a single row. Nevertheless, it should be appreciated thatmany hundreds and even thousands of rows of data may populate table 402at any given time in a complex system where each row includesinformation associated with a different currently established path.Source IP column 390 includes a source IP address for each openconnection path. Exemplary source IP address in column 390 is XJ234789.Destination IP column 392 includes a destination IP addresscorresponding an IP destination device within network 21 for eachaddress in column 390. Route path column 394 indicates a route path foreach connection path specified in table 402. In the illustrated example,the route path includes devices D4, D5, D6, etc.

Referring still to FIG. 22 column 396 is used to store a T-O connectionID for each of the route paths specified in column 394. In FIG. 22, anexemplary connection ID is T-O 1920. Column 398 is used to store an O-Tconnection ID corresponding to each of the route paths in column 394. InFIG. 22, exemplary connection ID in column 398 is O-T 0349. In column400, a separate connection serial number is provided for each of theroute paths in column 394.

Referring to FIGS. 1, 21 and 22, when an unconnected forward open packet370 is intercepted by firewall 30, firewall 30 decapsulates the packetand determines whether or not the source specified by the packet hasauthority to access the target network device specified by the packetfor any reason. Where the source has authority to access the targetnetwork device for any reason, firewall 30 populates a new connectionpath row in table 402 with information directly from the packet 370including providing information in columns 390, 392, 394 and 396. Whenfirewall 30 populates a new connection path row, firewall 30 alsogenerate a connection serial number and places the serial number iscolumn 400 correlated with the new connection path row. Thus, at thispoint, all of the new connection path row information in table 402 isspecified except for an entry in column 398. When a source does not haveauthority to access the target network device for at least one reason,the firewall does not create a new connection path row in table 402 andmay perform some type of secondary security function.

Continuing, after a new connection path row is partially populated,firewall 30 transmits a packet 370 along with the connection serialnumber via the designated non-IP route path to the target networkdevice. This subpacket is not illustrated. As a packet is received byeach of the non-IP network devices during routing to the target device,each of the route devices decapsulates the received packet, identifiesthe device from which the packet was received, the next device along theroute path to which to transmit a subpacket and the connection serialnumber, stores identification of the previous device and next devicealong with the connection serial number in a table akin to forward opentable 402 for subsequent routing and then transmits a subpacket to thenext device along the prescribed path until the target receives asubpacket.

When the target network device receives the subpacket including the T-OID and the connection serial number, the target device recognizes thesubpacket as a forward open request and in turn generates an unconnectedforward open reply data packet that is transmitted back along theconnection path to the firewall 30. In FIG. 23, an exemplary unconnectedforward open reply packet 410 is illustrated that includes a generalservice type field 414, a T-O ID field 416, an O-T ID field 418, aconnection serial number field 419 and a non-IP address field 412 (thisfield 412 may be optional). Field 414 specifies the general service type(i.e., an unconnected forward open reply in the present case). Field 416includes the T-O ID which is required by the target device tocommunicate with the source (i.e., the source will not acceptcommunications from the target device without the T-O ID). Field 418includes an O-T ID which is generated by the target network device andwhich is required in any communications from the source for the targetdevice to receive the communications. Field 419 includes the connectionpath serial number associated with the line of communication. Field 412indicates the non-IP address of the device in the non-IP connection paththat precedes the target device.

For instance, referring again to FIG. 1, where a non-IP connection pathincludes devices D4, D5, D6 . . . DN-1 and DN and device DN is thetarget device, the address specified in field 412 corresponds to deviceDN-1. When device DN-1 receives the packet, device DN-1 uses theconnection serial number in field 419 to identify the precedingconnection path device DN-2 via a lookup table stored by device DN-1 andtransmits a packet to that device. This process is repeated until deviceD4 receives a reply packet and uses information therefrom to generate anIP framed packet to be transmitted to the source. Here, the IP framedpacket includes, among other things, the T-O ID, the O-T ID and theconnection serial number corresponding to the connection path. When anIP packet is transmitted to the source, firewall 30 intercepts thepacket.

Referring still to FIGS. 1, 22 and 23, when firewall 30 intercepts theunconnected forward open reply packet, firewall 30 identifies the O-T IDand the connection serial number and inserts the ID in column 398 in therow associated with the connection serial number.

After the source receives the unconnected forward open reply, the sourcebegins communicating along the established connection path with thetarget network device without having to completely specify the non-IProuting path and hence communication overhead is reduced appreciably.Instead, the source need only specify the connection serial number whichis then used by the non-IP path network devices to route to next devicesalong the path until a packet is received by the target device.

Referring to FIG. 24, an exemplary connected send packet 420 which maybe transmitted by a source to a target network device after a connectionpath has been established is illustrated. Packet 420 includes source andIP destination address information in fields 302 and 303. A connectedsend type is indicated in general service type field 424. The O-T ID isspecified in field 426 and the connection serial number is specified infield 427. Here, a target object path/service field 428 is populatedwith an object path and a service to be performed on the objectindicated by the object path as described above. When a connected sendpacket 420 is intercepted by firewall 30, firewall 30 decapsulates thepacket, identifies the source, the target network device and the objectand service and uses that information to determine whether or not asubpacket should be transmitted on to the target network device.

Referring to FIG. 25, to close or eliminate a connection path, a sourcemay be programmed to transmit an unconnected forward close type packet430. Packet 430 includes source and IP destination information in fields302 and 303 as well as a general service type field 434 and a connectionserial number field 436. When a forward close packet 430 is interceptedby firewall 30, firewall 30 decapsulates the packet, identifies thepacket as a forward close type packet by examining the information infield 434, identifies the connection path serial number in field 436 andthen discontinues the connection path by deleting the row correspondingthereto in table 402 (see again FIG. 22). In addition, firewall 30allows disconnect information to be transmitted along the connectionpath causing devices therealong to delete path related information fromtheir memories.

Referring now to FIGS. 26 and 27, an exemplary method 450 forestablishing an authorized connection path between a source and a targetdevice for communicating along the path and for eliminating anestablished connection path is illustrated. Referring also to FIGS. 1and 22, at block 452, firewall 30 monitors packets that are targetingnetwork 21 devices. Where a forward open request is not received atdecision block 454, control passes to block 483 in FIG. 27. Where aconnected send packet is not identified at block 483 (here it is assumedthat a connection path has previously been specified and instantiated ina firewall forward open table), control passes to block 498. If anunconnected forward close packet is not identified at block 498, controlpasses back up to block 452 where monitoring of intercepted packetscontinues.

Referring again to FIGS. 1, 22 and 26, when a forward open request isreceived at decision block 454, control passes to block 456 wherefirewall 30 decapsulates the intercepted packet to identify the sourceof the packet, the target network device, the non-IP path throughnetwork 21 and the T-O connection ID. At block 458, firewall 30 accessesthe stored AC database 562 (see FIG. 28). At block 460, firewall 30 usesthe AC database 562 to determine if the source has authority to connectto the target network device for any purpose. At block 462, where thesource does not have authority to connect to the target network device,control passes to block 482 where a secondary security function akin toone of the functions described above is performed. After block 482,control passes to block 483 in FIG. 27.

Referring again to decision block 462, where the source has authority toconnect to the target network device for at least one purpose, controlpasses to block 464 where firewall 30 assigns a connection serial numberto the connection path between the source and the target network device.At block 468, firewall 30 populates a portion of a new row of theforward open table 402 with information including the source IP address,the destination IP address, the route path and the T-O connection ID. Atblock 470, firewall 30 transmits a packet via the non-IP path specifiedby the unconnected forward open request packet to the target networkdevice that includes the connection serial number and the T-O ID. Atblock 472, the target network device encapsulates an unconnected forwardopen reply (see FIG. 23) including an O-T connection ID and transmitsthat reply to the source. Firewall 30 intercepts the reply packet and,at block 474, the decapsulates the unconnected forward open reply andidentifies the O-T connection ID and uses that ID to complete theconnection path row in forward open table 402 at block 478. At block480, the non-IP network device that separates other network 21 devicesfrom the IP network (e.g., device D4 in the present example) generatesan IP protocol reply which is transmitted back to the source and thatincludes the O-T connection ID as well as the connection serial numbercorresponding to the newly open connection path. After block 480,control passes to block 483 in FIG. 27. At this point, a new connectionpath has been established and is instantiated in table 402.

Referring to FIG. 27 and also to FIGS. 1 and 22, at block 483, firewall30 monitors intercepted dual protocol packets targeting network 21devices for a connected send packet. When a connected send packet isintercepted, control passes to block 486. At block 486 firewall 30decapsulates a receive packet to access the connection serial number andthereby identify the connection path associated with the connected sendpacket. At block 488, firewall 30 access the forward open table 402 andidentifies the route path associated with the connection serial numberas well as the target network device. At block 490, firewall 30 accessesthe stored AC database 562 (see FIG. 28) and at block 492 firewall 30determines if the intended function or service is allowed. At block 494,where the service is not allowed, control passes to block 506 where asecondary security function is performed. After block 506, controlpasses back up to block 452 in FIG. 26 where the monitoring processcontinues. At block 494, where the function is allowed, control passesto block 496 where firewall 30 transmits the connected send packetincluding the T-O connection ID and the connection serial number to thetarget network device along the path indicated in route path column 394(see specifically FIG. 22).

Referring again to decision block 483, where a connected send packet hasnot been intercepted, control passes to block 498 where firewall 30determines whether or not a forward close packet has been intercepted.When a forward close packet has not been intercepted, control passesback to block 452 in FIG. 26 where monitoring continues. When a forwardclose packet is intercepted at block 498, control passes to block 500where firewall 30 accesses forward open table 402 (see again FIG. 22)and identifies the connection path row associated with the connectionserial number in the forward close packet. At block 502, firewall 30deletes the connection path associated with the connection serial numberin the forward close packet and control passes back up to block 452 inFIG. 26 where monitoring continues. After a connection path row has beendeleted from table 402, if additional communications are attempted usingthe connection serial number associated with the deleted row, firewall30 does not allow the communications.

A communication of this type is referred to hereinafter as an“unconnected send” because, as the label implies, a packet is sent inone direction and a connection is not set up between the source anddevice.

In at least some contemplated embodiments it has been recognized thatwhen a firewall denies a request from a source (e.g., a server, acomputer, a network device, etc.), the source can get “hung up” during atimeout period (e.g., 10 seconds) if a properly formatted response tothe request is not received. To this end, many sources maintain singlestring communication stacks for communicating on a network. Forinstance, referring to FIG. 29, a system 600 is illustrated where aserver 590 performs five applications A1-A5 and maintains a CIP stack592 that lists requests 001, 012, etc. from the applications. A pointer594 indicates a current request 011 in the stack that has most recentlybeen transmitted 604 to a target device via network 26. Consistent withFIG. 1, firewall 30 intercepts the request 001 and determines if therequest is to be halted or continued. In at least some applications,after a request is transmitted 604, server 590 will wait for a responseor the end of a timeout period before processing the next request in thestack 592.

In at least some applications timeout periods should be minimized tofacilitate fast processing of all requests in the CIP stack 592.According to another aspect of the present invention, when a firewall 30determines that a request should be denied, the firewall 30 isprogrammed to generate and transmit 606 a spoofed message back to therequesting server/source where the spoofed message has a format thatwill be recognized as a response to the request. When the requestingsource receives the spoofed message and recognizes the message as aproperly formatted response, the source processes the response andreleases the CIP stack so that the next stack request (e.g., 012 in thepresent example) can be processed.

Referring now to FIG. 30, an exemplary spoofed response packet 610 isillustrated that includes a source ID field 612, an IP destinationaddress field 614, an “Invalid Access Request” message field 616, aconnection SN field 617 and a T-O ID field 618. Source ID field 612indicates the original target device from the original request packetand field 614 indicates the address of the original source. In thepresent example the source may be the server 590 or server stack 592.Field 618 includes the target to originator ID (i.e., the T-O ID) fromthe original request. Here, the information in fields 612, 614, and 618is all information that is required by the source to accept the packet610 as a response to the associated request packet.

In at least some cases, some of the information (e.g., source and targetidentifying information) in the response packet fields will be gleanedor obtained from the original request communication packet. In somecases, other information such as the connection SN in field 617 will be“bogus” information fabricated by firewall 30 to trick the source intorecognizing a communication as a response from the target deviceintended for the source. For instance, where a request corresponds to anunauthorized communication, clearly no connection path is to be formedand therefore no connection SN will be required. However, if a sourcerequires a response packet that includes a serial number, a bogus orfake connection SN has to be generated and used to instantiate anappropriate field in a response packet.

Referring still to FIG. 30, field 616 includes a message or someindication akin thereto that the request was invalid or has been denied.The field 616 indication is used by the receiving source to perform someother function (e.g., indicate an error to a system user, begin aprocess to generate another request packet, etc.).

Referring now to FIG. 31, a method 620 for maintaining a single stringcommunication stack is illustrated. Referring also to FIG. 29, at block622, stack 592 receives a new request from one of the applications A1-A5associated therewith. At block 624, stack 592 adds the request to thestack. At block 626, server 590 accesses the next request in the stack(e.g., in a FIFO manner) and at block 628, server 590 encapsulates andtransmits a packet (see 370 in FIG. 21) corresponding to the next stackrequest to a corresponding target device via network 26. At block 630,stack 592 (or server 590) starts a timeout clock for the specificrequest.

Referring to FIG. 32, a sub-process 640 that may be substituted for aportion of the process illustrated in FIG. 20 is shown where thesub-process is for generating a spoofed response packet when a requestis denied. Referring also to FIG. 29, when firewall 30 receives arequest on a network 26, at block 632, firewall 30 determines if therequest should be halted or further processed. Where the request shouldbe further processed, control passes back to block 364 in FIG. 20.

At block 632, where the request is to be halted for lack of authority,control passes to block 634. At block 634, firewall 30 generatesinformation required to encapsulate a spoofed response. In the presentexample, referring again to FIG. 30, the required information to begenerated will include, in at least some applications, a connectionserial number (SN) as well as a rejection message for instantiatingfields 617 and 616, respectively. Here, it should be appreciated thatthe data generated at block 634 will depend on requirements set by thesource (e.g., server 590) and the type of protocol and therefore thatother types of spoofed information may be generated. The important pointhere is that the spoofed data/information and the packet formatencapsulated at block 636 should result in a packet that will bereceived as a properly formatted and legitimate response by the originalsource. At block 636, a response packet is encapsulated and at block 638the packet is transmitted to the originating source device.

Referring again to FIGS. 29 and 31, at block 642, server 590/stack 592monitors network 26 for a response that includes properly formatted andrequired data (e.g., the correct source and destination, a SN, theappropriate T-O ID, etc.). At block 644, when a response that meets theformat and content criteria of a proper response is not received,control passes to block 648 where server 590 monitors the timeout clock.When the timeout period has not expired, control loops back up to block642. When the time out period expires at block 648, control passes backup to block 622 where the process described above is repeated.

Referring still to FIGS. 29 and 31, when a response that meets theformat and content criteria of a proper response is received, controlpasses to block 646 where the response is processed. Here, in the caseof a spoofed response, the receiving server/source may simply indicateto a system operator that an error has occurred. In other cases theerror may prompt an associated application to generate a followingrequest.

While the CIP example herein is described in the context of a firewallthat is separate from the non-IP network devices, it should beappreciated that, in at least some embodiments, the firewallfunctionality may be embedded within a non-IP network device (e.g., aPLC) that is dedicated to firewall activities or in a non-IP networkdevice that performs other functions in addition to firewall activities.

Referring again to FIG. 1, in at least some embodiments it iscontemplated that when a persistent connection path is created between asource (e.g., S1) and a non-IP network device (e.g., DN),communications/transmissions should generally be regular such that theperiod between consecutive transmissions. is no longer than a maximumduration. Here, when more than a maximum duration or a maximum timeoutperiod occurs since a most recent packet transmission on a specificconnection path, a firewall may be programmed to close the connectionpath by deleting the path from the forward open table.

To this end, referring also to FIG. 22, forward open table 402 may, inaddition to the columns described above, include a connection timeoutcolumn 600 and a timer column 602. Timeout column 600 includes aseparate timeout period (e.g., TOP1) for each of the connection pathserial numbers in column 400. The timeout periods may be specified bysource devices that initiate connection paths or may be generated by afirewall in at least some embodiments. The timeout periods may all bethe same or may be connection path specific. Timer column 602 includes atimer value (e.g., TI1) for each timeout period in column 600. Eachtimer starts at a zero value when a forward open request is received andis reset to a zero value when a transmission along a related connectionpath is received by the firewall. When a timer value exceeds anassociated timeout period in column 600, the firewall closes theassociated communication path.

In addition, while the spoofed response process is described above inthe context of a server as a source, it should be appreciated that manysystem components and even applications may include a single stringstack and may be hung up when a firewall receives an unauthorizedrequest. In at least some cases it is contemplated that a firewall maybe programmed to spoof any application or component that generates arequest for which a response is required. Here, the formats and requireddata in the different responses may be different but the spoofingprinciple is the same. The firewall will simply be programmed togenerate several different types of spoofed messages for return torequest sources and will generate the appropriate message for eachsource.

Moreover, while the examples above are described in the context ofspecific types of first and second protocols, it should be appreciatedthat at least some inventive embodiments are independent of protocoltype (i.e., the first or framing protocol may be other than an Ethernetprotocol and the embedded protocol may be any protocol employed in theindustrial industries).

Furthermore, to be clear, in at least some applications it iscontemplated that the embedded messages could be nested. For instance,an Ethernet message may contain a CIP message with a first embeddeddestination which in turn may contain a CIP or other protocol messagewith yet another or second embedded distinction and so on. Here, in atleast some application, the firewall concept may cause a processor toevaluate one, or all or a subset of the embedded destinations andintended activities when a n-tier encapsulation occurs.

In addition, while the invention above is described in the context ofdatabases that specify access control information for destinationresources, it should be appreciated that the invention also contemplatesspecifying access controlling information for source resources. Forinstance, a database may specify that a specific workstation or handheld device associated with a specific user can only be used to accessand manipulate specific resources. Here, after decapsulation of apacket, a processor uses the access controlling information to determineif transmission should be restricted. Thus, where access controlinformation is specified, specification should be viewed broadly unlessotherwise indicated to include any data form that specifies access rulesrelated to resources regardless of whether the database rules are basedon destination or source resources.

To apprise the public of the scope of this invention, the followingclaims are made:

What is claimed is:
 1. A method for controlling access in an electronicnetwork, comprising: receiving a communication from a source device, thecommunication comprising a first protocol packet having first protocolpacket information including a first protocol destination resourceidentifier, wherein a second protocol packet is embedded in the firstprotocol packet; retrieving at least one access rule based on at leastone characteristic of the second protocol packet; applying the at leastone access rule to at least one characteristic of the first protocolpacket to determine an access rule outcome; and controlling access ofthe communication to a first protocol destination resource associatedwith the first protocol destination resource identifier according to theaccess rule outcome.
 2. The method of claim 1, wherein retrieving atleast one access rule comprises accessing the at least one access rulefrom an external access control database.
 3. The method of claim 1,wherein controlling access of the communication further comprisesrestricting access a second protocol destination resource when theaccess rule outcome indicates that the second protocol destinationresource is within a control configuration.
 4. The method of claim 1,wherein the at least one access rule comprises at least one zonedesignation.
 5. The method of claim 4, wherein controlling access of thecommunication to the first protocol destination resource furthercomprises restricting access when the access rule outcome indicates thatthe source device is outside the at least one zone designation.
 6. Themethod of claim 4, wherein controlling access of the communication tothe first protocol destination resource further comprises restrictingaccess when the access rule outcome indicates that the source device isinside the at least one zone designation.
 7. The method of claim 1,wherein the at least one access rule is configured via at least onecentral administrator interface.
 8. The method of claim 7, furthercomprising receiving the at least one access rule via the at least onecentral administrator interface.
 9. The method of claim 1, wherein theat least one access rule specifies communication sources authorized tocommunicate with a second protocol destination resource specified in thesecond protocol packet and communication sources not authorized tocommunicate with the second protocol destination resource.
 10. Themethod of claim 9, further comprising generating a warning signal whenthe access rule outcome indicates that at least one of the communicationsources is not authorized to communicate with the second protocoldestination resource.
 11. The method of claim 10, further comprisingtransmitting the warning signal to a configuration server.
 12. Themethod of claim 1, wherein the first protocol packet is configured inaccordance with an IP protocol.
 13. The method of claim 1, wherein theat least one characteristic of at least one of the first protocol packetand the second protocol packet comprises a source identifier associatedwith the source device.
 14. The method of claim 13, wherein the sourceidentifier comprises an IP address.
 15. The method of claim 13, whereinthe source identifier comprises an Ethernet address.
 16. The method ofclaim 1, wherein the second protocol packet is configured according to acommon industrial protocol.
 17. The method of claim 1, wherein thesecond protocol packet is configured according to a Data Highway Plusprotocol.
 18. The method of claim 1, wherein the first protocol packetis configured in accordance with an Ethernet/IP protocol.
 19. The methodof claim 1, wherein the at least one characteristic of the secondprotocol packet is at least one of a command, a service, an object, andan address filter.
 20. The method of claim 1, wherein controlling accessof the communication to the first protocol destination resource furthercomprises halting transmission of the first protocol packet when theaccess rule outcome indicates an unauthorized access attempt.
 21. Themethod of claim 1, wherein the second protocol packet specifies a paththrough a plurality of path resources, and wherein the at least oneaccess rule includes access control information associated with at leastone of the path resources.
 22. The method of claim 1, wherein the secondprotocol packet specifies a path through a plurality of path resources,and wherein the at least one access rule includes access controlinformation associated with each of the path resources.
 23. An apparatusfor controlling access in an electronic network, comprising: a memory; aprocessor disposed in communication with the memory and configured toissue processing instructions stored in the memory to: receive acommunication from a source device, the communication comprising a firstprotocol packet having first protocol packet information including afirst protocol destination resource identifier, wherein a secondprotocol packet is embedded in the first protocol packet; retrieve atleast one access rule based on at least one characteristic of the secondprotocol packet; apply the at least one access rule to at least onecharacteristic of the first protocol packet to determine an access ruleoutcome; and control access of the communication to a first protocoldestination resource associated with the first protocol destinationresource identifier according to the access rule outcome.
 24. Theapparatus of claim 23, wherein the apparatus is programmable to retrieveat least one access rule from an external access control database. 25.The apparatus of claim 23, wherein the apparatus is programmable torestrict access to a second protocol destination resource when theaccess rule outcome indicates that the second protocol destinationresource is within a control configuration.
 26. The apparatus of claim23, wherein the apparatus is programmable to connect to a centraladministrator interface, wherein the central administrator interface isprogrammable to create the at least one access rule.
 27. Anon-transitory processor-accessible medium storing processor-issuableinstructions to: receive a communication from a source device, thecommunication comprising a first protocol packet having first protocolpacket information including a first protocol destination resourceidentifier, wherein a second protocol packet is embedded in the firstprotocol packet; retrieve at least one access rule based on at least onecharacteristic of the second protocol packet; apply the at least oneaccess rule to at least one characteristic of the first protocol packetto determine an access rule outcome; and control access of thecommunication to a first protocol destination resource associated withthe first protocol destination resource identifier according to theaccess rule outcome.
 28. A method for restricting transmission of aprotocol packet between a source device and a destination device linkedon a network, the method comprising: intercepting a first protocolpacket having a second protocol packet embedded within the firstprotocol packet, wherein the second protocol packet includes adestination identifier that identifies a destination device for thesecond protocol packet; examining at least a portion of the embeddedsecond protocol packet to identify the destination device; identifyingaccess control information associated with the destination device;identifying a first protocol packet characteristic; comparing the firstprotocol packet characteristic to the access control informationassociated with the destination device; and restricting transmission ofthe first protocol packet as a function of the access controlinformation and the first protocol packet characteristic.